Bug#527581: considering NMU
Henrique de Moraes Holschuh
> I am considering uploading a DELAYED 7 NMU for this bug
> tonight or tomorrow. HMH, if you have plans to review the
> patch please let us know roughly when you might manage this
> and I will not upload the NMU.
Well, I have some problems with the patch.
I am not a groupie of the school of undue complexity so that we can revert
our build trees to whatever shit came from upstream. A debian source
package exists to build debian binary packages. I consider the entire
"revert" stuff useless complexity.
The second one, is that it does too little. It doesn't help the configure
call with proper parameters, it doesn't help setting up debian/control
dependencies, it doesn't handle updating the autotools stuff (GNU config !=
autotools, although autotools needs it). It just freshes up
config.sub/config.guess -- so the dh_autotools name is incorrect.
This is easy to fix. Rename it to dh_update_gnu_config or something shorter
but to that effect.
However, do we _really_ need a wrapper to do something that boils down to:
rm -f config.{sub,guess}
in the clean target, and
ln -sf /usr/share/misc/config.{sub,guess} .
in the target that will call configure, plus a build-dependency on
autotools-dev ?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Resul Cetin
> On Tue, 17 Nov 2009, Jon Dowland wrote:
> > I am considering uploading a DELAYED 7 NMU for this bug
> > tonight or tomorrow. HMH, if you have plans to review the
> > patch please let us know roughly when you might manage this
> > and I will not upload the NMU.
>
> Well, I have some problems with the patch.
>
> I am not a groupie of the school of undue complexity so that we can revert
> our build trees to whatever shit came from upstream. A debian source
> package exists to build debian binary packages. I consider the entire
> "revert" stuff useless complexity.
Please don't change the diff.gz/debian.tar.gz instead of the package author.
The patch does the only sane thing possible.
Best regards,
Resul
Henrique de Moraes Holschuh
> > package exists to build debian binary packages. I consider the entire
> > "revert" stuff useless complexity.
> So that the next rebuild notices a change in the config.guess/.sub? Forget it.
Did you even read the README? I don't think it avocates leaking crap to
diffs. In fact, I recall it recommends rm -f config.sub config.guess in
debian/rules' clean target.
Are you aware that any proper Debian package has to trash upstream's
autoconf/autoheader/libtool/automake/gettext/autopoint -generated files, and
"autoreconf" everything using the Debian versions of autotools? This is the
recommended way of doing things, so that the backage builds with appropriate
versions of the autotools engines, AND so that a binNMU is enough to
propagate fixes, e.g., in libtool to the packages.
Yes, a big lot of packages don't do the above, which is not optimal, but we
deal with it through mass bug filings when required (argh).
If a DD follows the "debian/rules clean should give you the upstream
tarball" school, that means he would need a fully separate build-tree, where
he copy everything of interest there, modify, patch, and build. This
doesn't mix well with dpkg-managed patches. The proposed dh_ script is not
optimal for this scenario, it needs to have (optional?) parameters to tell
it where to install the config.* files.
If the DD doesn't follow that school (most don't, AFAIK), he has to rm -f
all autogenerated files in debian/rules' clean target or they will leak to
the diff anyway. At that point the tree needs special steps to get back to
the "./configure ; make ; make install" state anyway, and rm -f
config.sub/guess is easier.
If the DD wants things half-way, i.e. have the tree buildable upstream'
style, he is going to screw us over (the mass bugfilling) OR leak autotools
crap to the diff. There is no possible middle-ground.
Now, you see why I think the proposed script is not that useful?
> The patch does the only sane thing possible.
I don't agree (see above). But even if I do include it, it will not be
under the dh_autotools name. It doesn't do even HALF of what it would have
to do to deserve that name. Thus, the dh_autotools name is vetoed. Please
rename it to dh_update_gnuconfig or something like that.
CDBS does a lot more setup to ease autotools usage, maybe it would be a good
idea to look at what it does, and try to translate a more complete set of
functionality for a "dh_autotools"? That will either need some hooking to
debhelper internals, or two separate tools, one for clean, the other for
pre-config setup.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
Resul Cetin
> > > package exists to build debian binary packages. I consider the entire
> > > "revert" stuff useless complexity.
> >
> > So that the next rebuild notices a change in the config.guess/.sub?
> > Forget it.
>
> Did you even read the README? I don't think it avocates leaking crap to
> diffs. In fact, I recall it recommends rm -f config.sub config.guess in
> debian/rules' clean target.
>
> Are you aware that any proper Debian package has to trash upstream's
> autoconf/autoheader/libtool/automake/gettext/autopoint -generated files,
> and "autoreconf" everything using the Debian versions of autotools? This
> is the recommended way of doing things, so that the backage builds with
> appropriate versions of the autotools engines, AND so that a binNMU is
> enough to propagate fixes, e.g., in libtool to the packages.
>
> Yes, a big lot of packages don't do the above, which is not optimal, but we
> deal with it through mass bug filings when required (argh).
>
> If a DD follows the "debian/rules clean should give you the upstream
> tarball" school, that means he would need a fully separate build-tree,
> where he copy everything of interest there, modify, patch, and build.
> This doesn't mix well with dpkg-managed patches. The proposed dh_ script
> is not optimal for this scenario, it needs to have (optional?) parameters
> to tell it where to install the config.* files.
able to do a autoreconf - so you can use your README for whatever you want.
> If the DD doesn't follow that school (most don't, AFAIK), he has to rm -f
> all autogenerated files in debian/rules' clean target or they will leak to
> the diff anyway. At that point the tree needs special steps to get back to
> the "./configure ; make ; make install" state anyway, and rm -f
> config.sub/guess is easier.
>
> If the DD wants things half-way, i.e. have the tree buildable upstream'
> style, he is going to screw us over (the mass bugfilling) OR leak autotools
> crap to the diff. There is no possible middle-ground.
>
> Now, you see why I think the proposed script is not that useful?
>
> > The patch does the only sane thing possible.
>
> I don't agree (see above). But even if I do include it, it will not be
> under the dh_autotools name. It doesn't do even HALF of what it would have
> to do to deserve that name. Thus, the dh_autotools name is vetoed. Please
> rename it to dh_update_gnuconfig or something like that.
>
> CDBS does a lot more setup to ease autotools usage, maybe it would be a
> good idea to look at what it does, and try to translate a more complete
> set of functionality for a "dh_autotools"? That will either need some
> hooking to debhelper internals, or two separate tools, one for clean, the
> other for pre-config setup.
CDBS tells use "don't do that... just copy config.guess and config.sub and
later restore everything".
CDBS can be asked to update libtool, autoconf, and automake files, but this
behavior is likely to break the build system and is STRONGLY discouraged
Best regards,
Resul
Henrique de Moraes Holschuh
> > Did you even read the README? I don't think it avocates leaking crap to
> > diffs. In fact, I recall it recommends rm -f config.sub config.guess in
> > debian/rules' clean target.
> >
> > Are you aware that any proper Debian package has to trash upstream's
> > autoconf/autoheader/libtool/automake/gettext/autopoint -generated files,
> > and "autoreconf" everything using the Debian versions of autotools? This
> > is the recommended way of doing things, so that the backage builds with
> > appropriate versions of the autotools engines, AND so that a binNMU is
> > enough to propagate fixes, e.g., in libtool to the packages.
> >
> > Yes, a big lot of packages don't do the above, which is not optimal, but we
> > deal with it through mass bug filings when required (argh).
> >
> > If a DD follows the "debian/rules clean should give you the upstream
> > tarball" school, that means he would need a fully separate build-tree,
> > where he copy everything of interest there, modify, patch, and build.
> > This doesn't mix well with dpkg-managed patches. The proposed dh_ script
> > is not optimal for this scenario, it needs to have (optional?) parameters
> > to tell it where to install the config.* files.
> Yes, autohell is broken by design for distributions. Most packages will not be
> able to do a autoreconf - so you can use your README for whatever you want.
Hmm? You have a halfway-done packaging, then. Yes, often there are bugs in
the build system, which is your job to fix AS WELL. If you can't deal with
the build system of something, don't package it.
auto* are ugly, and I don't object to the autohell moniker, but there is no
design problem for distros that require a full rebuild (which Debian
__DOES__) per policy. The README is a bit outdated, there is some stuff
there from 5 years ago when we didn't want rebuilds because it was hard on
the slower buildds. This is not a problem anymore, even ARM is fast enough.
I am aware of _one_ bug that gets in the way: autoreconf is dumb and can't
do aclocal -I somedir. One works around that by calling the required
autotools directly (which is much faster than autoreconf, anyway).
> > CDBS does a lot more setup to ease autotools usage, maybe it would be a
> > good idea to look at what it does, and try to translate a more complete
> > set of functionality for a "dh_autotools"? That will either need some
> > hooking to debhelper internals, or two separate tools, one for clean, the
> > other for pre-config setup.
> CDBS tells use "don't do that... just copy config.guess and config.sub and
> later restore everything".
Then they're going (again) against the best practice.
> CDBS can be asked to update libtool, autoconf, and automake files, but this
> behavior is likely to break the build system and is STRONGLY discouraged
Strongly discouraged by whom? The peanut gallery?
You're encouraged to do it right. If you're not going to do it right, then
it is best that you don't break it worse. How THAT became "you're STRONGLY
discouraged to autoretool", I don't know.
You build-dep on *tested* version of the autotools (there will be at least
one, the one you're using!), and either call them directly or set the
environment variables and call autoreconf. Nobody said you have to use the
latest major release of the autotools, we fix them all when there's
something that needs fixing, and the only ones that really cause problems
(and thus require fixes and package rebuilds) are gettext (now autopoint)
and libtool.
If you're upstream, and you are not doing a botched up job, you don't have
the autogenerated files in the VCS, and you have a script to retool it on
the clean checkouts before generating release drops anyway. So it is not a
problem to upstream authors that did it by the book, either.
If you want this patch in, rename the util to something like
dh_update_gnuconfig.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
Resul Cetin
> > > good idea to look at what it does, and try to translate a more
> > > complete set of functionality for a "dh_autotools"? That will either
> > > need some hooking to debhelper internals, or two separate tools, one
> > > for clean, the other for pre-config setup.
> >
> > CDBS tells use "don't do that... just copy config.guess and config.sub
> > and later restore everything".
>
> Then they're going (again) against the best practice.
>
> > CDBS can be asked to update libtool, autoconf, and automake files, but
> > this behavior is likely to break the build system and is STRONGLY
> > discouraged
>
> Strongly discouraged by whom? The peanut gallery?
>
> You're encouraged to do it right. If you're not going to do it right, then
> it is best that you don't break it worse. How THAT became "you're STRONGLY
> discouraged to autoretool", I don't know.
Best regards,
Resul
Henrique de Moraes Holschuh
> > > > CDBS does a lot more setup to ease autotools usage, maybe it would be a
> > > > good idea to look at what it does, and try to translate a more
> > > > complete set of functionality for a "dh_autotools"? That will either
> > > > need some hooking to debhelper internals, or two separate tools, one
> > > > for clean, the other for pre-config setup.
> > >
> > > CDBS tells use "don't do that... just copy config.guess and config.sub
> > > and later restore everything".
> >
> > Then they're going (again) against the best practice.
> >
> > > CDBS can be asked to update libtool, autoconf, and automake files, but
> > > this behavior is likely to break the build system and is STRONGLY
> > > discouraged
> >
> > Strongly discouraged by whom? The peanut gallery?
> The cdbs author. Ever read the cdbs doc?
No. I never had to do any maintenance on a CDBS-using package. But I did
recall they had provisions for calling the configure chain properly.
> > You're encouraged to do it right. If you're not going to do it right, then
> > it is best that you don't break it worse. How THAT became "you're STRONGLY
> > discouraged to autoretool", I don't know.
> This tells the cdbs author not I. Do you ever read the stuff you referring to?
I meant neither of you. That's the general way things get done in Debian,
and I am puzzled how, in autotools' case, it got switched from "try to do it
right" into "do it wrong, because it is easier and the bomb will go off on
someone else's lap".
I am not willing to discuss this further, it will piss me off.
Just to make it clear: I am waiting for a revised version of the patch, with
a different name. The current one will NOT get merged.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
Julian Andres Klode
> On Tue, 17 Nov 2009, Jon Dowland wrote:
> > I am considering uploading a DELAYED 7 NMU for this bug
> > tonight or tomorrow. HMH, if you have plans to review the
> > patch please let us know roughly when you might manage this
> > and I will not upload the NMU.
>
> Well, I have some problems with the patch.
>
> I am not a groupie of the school of undue complexity so that we can revert
> our build trees to whatever shit came from upstream. A debian source
> package exists to build debian binary packages. I consider the entire
> "revert" stuff useless complexity.
>
> The second one, is that it does too little. It doesn't help the configure
> call with proper parameters, it doesn't help setting up debian/control
> dependencies, it doesn't handle updating the autotools stuff (GNU config !=
> autotools, although autotools needs it). It just freshes up
> config.sub/config.guess -- so the dh_autotools name is incorrect.
I have written another debhelper script (dh_autoreconf), which calls autoreconf
-f -i and creates a list of files added/changed during the execution of the
command. Those files are then removed by dh_autoreconf_clean.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Julian Andres Klode
Scripts (no autoreconf.pm) are now at
http://svn.debian.org/viewsvn/pkg-gnome/packages/unstable/gnome-main-menu/debian/
If you want it in autotools-dev, just take dh_autoreconf* from there and
the autoreconf.pm from the tarball in my last email. I also removed -X
options from dh_autoreconf because they were almost useless.
Regards,
Julian
Fabian Greffrath
notfound 527581 20090611.1
found 527581 2.65-3
thanks
As the original author of the patches discussed here, I must say that I
like JAK's approach even more. However, since it calls autoreconf, it
should be reassigned to the autoconf (or maybe automake, CC'ed both
maintainers) package. Since it's still missing a debhelper sequence
addon, I've attached it to this mail.
@Resul: The only reason why my patch used the backup-and-restore
approach in the first place was to remember where the original files
initially were. If they were deleted in the clean rule, the
dh_autotools_update script would never have known where to copy the
files if the package was built twice in a row. With JAK's approach this
has become unnecessary.
- Fabian
Julian Andres Klode
> reassign 527581 autoconf
> notfound 527581 20090611.1
> found 527581 2.65-3
> thanks
>
> As the original author of the patches discussed here, I must say that I
> like JAK's approach even more. However, since it calls autoreconf, it
> should be reassigned to the autoconf (or maybe automake, CC'ed both
> maintainers) package. Since it's still missing a debhelper sequence
> addon, I've attached it to this mail.
missing in gnome-main-menu because it could not be used there directly
due to not being in the correct location.
Anyway, this approach should allow us to build packages including
autoreconf with a simple
%:
dh --with autoreconf $@
debian/rules file which would be great. If you don't want to libtoolize,
and the package includes the libtool macros (ltversion, etc.) you could
even do an "export LIBTOOLIZE := true" in rules, so autoreconf calls
true instead of libtoolize.
Regards,
Julian
--
Julian Andres Klode - Debian Developer, Ubuntu Member
--
Julian Andres Klode
> Fabian Greffrath <fab...@greffrath.com> writes:
>
> > As the original author of the patches discussed here, I must say that I
> > like JAK's approach even more. However, since it calls autoreconf, it
> > should be reassigned to the autoconf (or maybe automake, CC'ed both
> > maintainers) package. Since it's still missing a debhelper sequence
> > addon, I've attached it to this mail.
>
> to me from the bug log. The attachments and patches that I see
> look like changes to Debhelper.
He wants you to include the debhelper commands, because autoconf
includes autoreconf and those are special dh_* commands for autoreconf.
But they could also be included in debhelper directly if you think this
would be better (and if joeyh shares this opinion).
Ben Pfaff
> As the original author of the patches discussed here, I must say that I
> like JAK's approach even more. However, since it calls autoreconf, it
> should be reassigned to the autoconf (or maybe automake, CC'ed both
> maintainers) package. Since it's still missing a debhelper sequence
> addon, I've attached it to this mail.
What change to Autoconf do you want me to make? It's not clear
to me from the bug log. The attachments and patches that I see
look like changes to Debhelper.
--
Ben Pfaff
http://benpfaff.org
Fabian Greffrath
> Anyway, this approach should allow us to build packages including
> autoreconf with a simple
>
> %:
> dh --with autoreconf $@
> debian/rules file which would be great. If you don't want to libtoolize,
> and the package includes the libtool macros (ltversion, etc.) you could
> even do an "export LIBTOOLIZE := true" in rules, so autoreconf calls
> true instead of libtoolize.
Julien, I've got one thing to add to your scripts. You just check for
files that have been changed during autoreconf and remove them.
However, in most (all?) cases the directory autom4te.cache will be
created by autoreconf. Since I haven't found it to be of any use after
the autoreconf invocation, I suggest to remove it afterwards:
--- dh_autoreconf.orig
+++ dh_autoreconf
@@ -29,6 +29,7 @@
# Run autoreconf to recreate the needed files.
doit('autoreconf', '-f', '-i');
+doit('rm', '-f', '-r', 'autom4te.cache');
# Create a list of all the files (compared later on)
complex_doit('find -type f | xargs md5sum > debian/autoreconf.after');
- Fabian
Julian Andres Klode
> Julien, I've got one thing to add to your scripts. You just check for
> files that have been changed during autoreconf and remove them.
> However, in most (all?) cases the directory autom4te.cache will be
> created by autoreconf. Since I haven't found it to be of any use after
> the autoreconf invocation, I suggest to remove it afterwards:
well. But we don't have to care about new directories because
directories don't appear in a diff.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
--
Fabian Greffrath
> New files are also changed files in some way and will be removed as
> well. But we don't have to care about new directories because
> directories don't appear in a diff.
I know, but it "feels cleaner" to not have empty (and actually
useless) directories linger around after having "cleaned" the package.
So would you please? ;)
Joey Hess
> He wants you to include the debhelper commands, because autoconf
> includes autoreconf and those are special dh_* commands for autoreconf.
> But they could also be included in debhelper directly if you think this
> would be better (and if joeyh shares this opinion).
Regarding including these commands in debhelper, I am uncertian because
these commands would not be included in the default dh sequences, or the
example rules files, and that would be a first -- currently every
command in debhelper is included in the dh sequences and all except dh_auto_*
are included in the longer example rules files.
Adding an optional command to debhelper that likely does not do the
right thing for a fairly large percentage of packages (my experience
with running autoreconf and having it actually work, in the real world,
is not exactly stellar) would be a departure.
(It might make more sense to do this as one of debhelper's buildsystem
classes.)
I also have qualms about the implementation. Checksumming every file
in the source tree will really suck for large source trees on slow
architectures. Deleting any file that changes during a build could also
be quite suprising behavior. Builds do sometimes change random files
that it does not necessarily make sense to delete to revert out of the
Debian diff.
Is there really no better way to isolate autoreconf's changes to keep
them out of the diff? Since debhelper already supports running configure
and build in a temporary build directory, perhaps the simplifying
assumption needs to be that if autoreconf is used, a build directory has
to be used.
(Note that dh_clean already removes autom4te.cache.)
--
see shy jo
Julian Andres Klode
> Julian Andres Klode wrote:
> > He wants you to include the debhelper commands, because autoconf
> > includes autoreconf and those are special dh_* commands for autoreconf.
> > But they could also be included in debhelper directly if you think this
> > would be better (and if joeyh shares this opinion).
>
> Regarding including these commands in debhelper, I am uncertian because
> these commands would not be included in the default dh sequences, or the
> example rules files, and that would be a first -- currently every
> command in debhelper is included in the dh sequences and all except dh_auto_*
> are included in the longer example rules files.
>
> Adding an optional command to debhelper that likely does not do the
> right thing for a fairly large percentage of packages (my experience
> with running autoreconf and having it actually work, in the real world,
> is not exactly stellar) would be a departure.
This practice is recommended by the README.Debian of autotools-dev.
> (It might make more sense to do this as one of debhelper's buildsystem
> classes.)
>
> I also have qualms about the implementation. Checksumming every file
> in the source tree will really suck for large source trees on slow
> architectures. Deleting any file that changes during a build could also
> be quite suprising behavior. Builds do sometimes change random files
> that it does not necessarily make sense to delete to revert out of the
> Debian diff.
The scripts I provided only delete files that changed during autoreconf
and that seems to work very well in most cases. In cases where a file
should not be deleted, one could pass -X parameters to
dh_autoreconf_clean. But the scripts could maybe also use mtimes+size
instead of md5sums, although I haven't checked whether this works.
>
> Is there really no better way to isolate autoreconf's changes to keep
> them out of the diff? Since debhelper already supports running configure
> and build in a temporary build directory, perhaps the simplifying
> assumption needs to be that if autoreconf is used, a build directory has
> to be used.
You'd need to copy the whole source tree into the build directory for
autoreconf to work, as far as I know.
Henrique de Moraes Holschuh
Since you already asked if to be added to the autoconf package, I will just
keep monitoring the bug as long as I get the CCs. If you decide it is best
done in autotools-dev, when you reach the final version of the script,
reassign it to autotools-dev and attach a NMU patch. After that, if I don't
get back to you in a week, pester me for an upload.
Henrique de Moraes Holschuh
> > Adding an optional command to debhelper that likely does not do the
> > right thing for a fairly large percentage of packages (my experience
> > with running autoreconf and having it actually work, in the real world,
> > is not exactly stellar) would be a departure.
> This practice is recommended by the README.Debian of autotools-dev.
Autotools-dev "best practices" assume you did a full job on the build
system, and got it fixed if it is not properly rebuilding itself from
scratch.
It also assumes you sent any autogenerated files to kingdom come in the
debian/rules clean target (or moved them out of the way, if you're into
that).
If that stuff is in any way horked, or if it hits one of the autoreconf
bugs/shortcomings (e.g. autoreconf can't take a -I for aclocal), you need
to do something different.
> > Is there really no better way to isolate autoreconf's changes to keep
> > them out of the diff? Since debhelper already supports running configure
> > and build in a temporary build directory, perhaps the simplifying
> > assumption needs to be that if autoreconf is used, a build directory has
> > to be used.
> You'd need to copy the whole source tree into the build directory for
> autoreconf to work, as far as I know.
AFAIK, that's correct.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
Fabian Greffrath
> The scripts I provided only delete files that changed during autoreconf
> and that seems to work very well in most cases. In cases where a file
> should not be deleted, one could pass -X parameters to
> dh_autoreconf_clean. But the scripts could maybe also use mtimes+size
> instead of md5sums, although I haven't checked whether this works.
OK, now what's the consent on these scripts? Will they be included in
the next autoconf package?
- Fabian
Ben Pfaff
> OK, now what's the consent on these scripts? Will they be included in
> the next autoconf package?
I'm still trying to figure out exactly what I want to do. I
probably won't have time to actually take action until the
weekend, or perhaps Monday since it's a holiday here.
I'm a little concerned about maintaining a new set of scripts
that I don't use myself, so I would probably have to put in a bit
of time to convert my doschk or fmtools packages to use these
scripts too.
I'm not sure whether these should go into the "autoconf" binary
package or a separate binary package. I see both practices in
the archive.
--
"doe not call up Any that you can not put downe."
--H. P. Lovecraft
Fabian Greffrath
> I'm a little concerned about maintaining a new set of scripts
> that I don't use myself, so I would probably have to put in a bit
> of time to convert my doschk or fmtools packages to use these
> scripts too.
I believe the scripts will be widely used within a short time frame and
they are just a few lines of perl, so I think you won't stand alone with
their maintenance anytime. ;)
> I'm not sure whether these should go into the "autoconf" binary
> package or a separate binary package. I see both practices in
> the archive.
Maybe it would make sense to introduce an additional package
"dh-autoreconf" that depends on autoconf, automake and (at least
recommends) libtool; without these the autoreconf script IMHO doesn't
make much sense anyway. This package doesn't need to be necesarrily
maintained by you alone, though.
However, I am still thinking about shipping both sets of scripts, the
ones (i.e. mine) that simply update and restore config.{guess,sub}
(because that's really sufficient in some cases) and the other ones
(i.e. Julian's) that do the whole autoreconf.
@Joey: Would it be possible to make the scripts "depend" on each other?
If not, they could still "remove_command" each other in the dh sequence
file to not do duplicate work, just as in the python_central vs.
python-support case. Or?
@Henrique: If I renamed my initial scripts to dh_config-scripts_update
and dh_config-scripts_restore and renamed the dh sequence addon to
config-scripts.pm, would you then accept them in autotools-dev? The
actual names are still subject to discussion of course. ;)
Cheers,
Fabian
Ben Pfaff
> Am Mittwoch, den 10.02.2010, 12:43 -0800 schrieb Ben Pfaff:
>> I'm not sure whether these should go into the "autoconf" binary
>> package or a separate binary package. I see both practices in
>> the archive.
>
> Maybe it would make sense to introduce an additional package
> "dh-autoreconf" that depends on autoconf, automake and (at least
> recommends) libtool; without these the autoreconf script IMHO doesn't
> make much sense anyway. This package doesn't need to be necesarrily
> maintained by you alone, though.
This seems like a fine idea to me.
Once we decide to do that, though, I'm not sure that there's any
need for a connection to the Autoconf source package. It seems
to me that it could be maintained just as well completely
separately. I'm not eager to be the one to do that; I am already
overloaded.
I didn't see any responses to your questions below, either,
especially the one to Henrique, which could moot the need for a
dh-autoreconf package:
> However, I am still thinking about shipping both sets of scripts, the
> ones (i.e. mine) that simply update and restore config.{guess,sub}
> (because that's really sufficient in some cases) and the other ones
> (i.e. Julian's) that do the whole autoreconf.
>
> @Joey: Would it be possible to make the scripts "depend" on each other?
> If not, they could still "remove_command" each other in the dh sequence
> file to not do duplicate work, just as in the python_central vs.
> python-support case. Or?
>
> @Henrique: If I renamed my initial scripts to dh_config-scripts_update
> and dh_config-scripts_restore and renamed the dh sequence addon to
> config-scripts.pm, would you then accept them in autotools-dev? The
> actual names are still subject to discussion of course. ;)
--
Ben Pfaff
http://benpfaff.org
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/873a12j...@blp.benpfaff.org
Henrique de Moraes Holschuh
> @Henrique: If I renamed my initial scripts to dh_config-scripts_update
> and dh_config-scripts_restore and renamed the dh sequence addon to
> config-scripts.pm, would you then accept them in autotools-dev? The
Yes.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2010021613...@khazad-dum.debian.net
Fabian Greffrath
Holschuh:
> Would you agree on _updateconfig and _restoreconfig ?
I've prepared an NMU to finally implement this feature, please find it
attached to this mail. I tried to stay close to what has been done in
the quilt package, but refrained from changing documentation, package
description etc.
Cheers,
Fabian
Henrique de Moraes Holschuh
Looks good, feel free to upload it when you feel like it.
Fabian Greffrath
> Looks good, feel free to upload it when you feel like it.
Thanks, but I am not a DD and have no upload rights. :(
Henrique de Moraes Holschuh
> Am 17.02.2010 20:50, schrieb Henrique de Moraes Holschuh:
> >Looks good, feel free to upload it when you feel like it.
>
> Thanks, but I am not a DD and have no upload rights. :(
Well, I will get to it soon enough, and any other DD that is in the loop,
feel free to upload the NMU.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
Fabian Greffrath
Henrique de Moraes Holschuh:
> On Thu, 18 Feb 2010, Fabian Greffrath wrote:
>> > Am 17.02.2010 20:50, schrieb Henrique de Moraes Holschuh:
>>> > >Looks good, feel free to upload it when you feel like it.
>> > Thanks, but I am not a DD and have no upload rights. :(
> I am fine with those changes as well.
> Well, I will get to it soon enough, and any other DD that is in the loop,
> feel free to upload the NMU.
I have prepared packages and put them on mentors.d.n, please upload:
<http://mentors.debian.net/debian/pool/main/a/autotools-dev/autotools-dev_20090611.1+nmu1.dsc>
Cheers,
Fabian