Bug#559098: config.sub/guess updating
On Tue, 01 Dec 2009, Joey Hess wrote: > override_dh_auto_configure: > ln -sf /usr/share/misc/config.sub . > ln -sf /usr/share/misc/config.guess . > dh_auto_configure > > override_dh_auto_clean: > dh_auto_clean > rm -f config.sub config.guess Looks good. However, be adivised that there is a line of thought that defends doing mv config.sub config.sub.useless, and moving that back on clean. I don't subscribe to that line of thought, but some others do. > * Modify debhelper's automake buildsystem to handle the config.sub on its own. > This would probably only be suitable for a new compat level, as it risks > breaking weird packages. Another problem is that either debhelper or the > source package would need to depend on autotools-dev. > We probably don't want debhelper to have that dependency, but if the > source package forgot to add a build-depends, it would build inconsistently > and probably fai on just those autobuilders where the new config.sub is > needed. > > * Add commands with names such as dh_autotools_update and dh_autotools_clean > to autotools-dev itself. Plus a debhelper sequence addon, so users could > enable them via "dh $@ --with autotools-dev". I am fine with either, but I'd propose to change the name from *_autotools_*, to *_gnuconfig_*. The reasoning for that request is that autotools_update is not updating the autotools (it is not retooling, updating libtool, etc), it is just updating GNU config (config.sub/config.guess). -- "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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559098: config.sub/guess updating
Hello,
On trečiadienis 02 Gruodis 2009 02:43:18 Joey Hess wrote:
> Modestas Vainius wrote:
> > * Isn't this a perfect use case for a build system specific option
> > (#543507)? You could enable this config.sub handling in autoconf.pm if
> > e.g. --autotools- prep is passed to dh_auto_*. In my opinion, inventing
> > another two dh_* commands is kind of overkill since this
> > config.{sub,guess} stuff is pretty much autoconf specific. What is more,
> > this way not only dh users could benefit from this but also packages
> > calling dh_auto_{configure,clean} directly.
>
> Maybe, if the option failed when autotools-dev was not installed, so
> that builds are consistent.
Of course. Actually, this option must fail if autotools-dev is not installed.
Maintainer did A (specified the option), but didn't do B (didn't add
autotools-dev build-depend for the package) => bug in the package, i.e. FTBFS.
--
Modestas Vainius
signature.asc
Description: This is a digitally signed message part.
Bug#559098: config.sub/guess updating
Modestas Vainius wrote:
> * Isn't this a perfect use case for a build system specific option (#543507)?
> You could enable this config.sub handling in autoconf.pm if e.g. --autotools-
> prep is passed to dh_auto_*. In my opinion, inventing another two dh_*
> commands is kind of overkill since this config.{sub,guess} stuff is pretty
> much autoconf specific. What is more, this way not only dh users could
> benefit
> from this but also packages calling dh_auto_{configure,clean} directly.
Maybe, if the option failed when autotools-dev was not installed, so
that builds are consistent.
--
see shy jo
signature.asc
Description: Digital signature
Bug#559098: config.sub/guess updating
Hello,
On antradienis 01 Gruodis 2009 23:53:09 Joey Hess wrote:
> So, it would probably be nice if there were some way to avoid needing this
> boilerplate when using a minimal rules file. I can see basically two ways
> to do it:
>
> * Modify debhelper's automake buildsystem to handle the config.sub on its
> own. This would probably only be suitable for a new compat level, as it
> risks breaking weird packages. Another problem is that either debhelper or
> the source package would need to depend on autotools-dev.
> We probably don't want debhelper to have that dependency, but if the
> source package forgot to add a build-depends, it would build
> inconsistently and probably fai on just those autobuilders where the new
> config.sub is needed.
>
> * Add commands with names such as dh_autotools_update and
> dh_autotools_clean to autotools-dev itself. Plus a debhelper sequence
> addon, so users could enable them via "dh $@ --with autotools-dev".
* Isn't this a perfect use case for a build system specific option (#543507)?
You could enable this config.sub handling in autoconf.pm if e.g. --autotools-
prep is passed to dh_auto_*. In my opinion, inventing another two dh_*
commands is kind of overkill since this config.{sub,guess} stuff is pretty
much autoconf specific. What is more, this way not only dh users could benefit
from this but also packages calling dh_auto_{configure,clean} directly.
--
Modestas Vainius
signature.asc
Description: This is a digitally signed message part.
Bug#559098: config.sub/guess updating
Package: debhelper Version: 7.4.8 Severity: wishlist Probably a lot of dh using packages will need to do something like this: override_dh_auto_configure: ln -sf /usr/share/misc/config.sub . ln -sf /usr/share/misc/config.guess . dh_auto_configure override_dh_auto_clean: dh_auto_clean rm -f config.sub config.guess Actually, only config.sub should be needed since dh_auto_configure passes arch info to configure. Also, the above is not optimal since it triggers warnings from dpkg-source about the removed files. It's probably better to preserve and replace the original files in clean. And that kind of sublety is why we like to put such things in reusable and improvable debhelper commands, of course. So, it would probably be nice if there were some way to avoid needing this boilerplate when using a minimal rules file. I can see basically two ways to do it: * Modify debhelper's automake buildsystem to handle the config.sub on its own. This would probably only be suitable for a new compat level, as it risks breaking weird packages. Another problem is that either debhelper or the source package would need to depend on autotools-dev. We probably don't want debhelper to have that dependency, but if the source package forgot to add a build-depends, it would build inconsistently and probably fai on just those autobuilders where the new config.sub is needed. * Add commands with names such as dh_autotools_update and dh_autotools_clean to autotools-dev itself. Plus a debhelper sequence addon, so users could enable them via "dh $@ --with autotools-dev". I'm interested in the autotools-dev maintainer's opinion of this, especially of the second option. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.31-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages debhelper depends on: ii binutils 2.20-4 The GNU assembler, linker and bina ii dpkg-dev 1.15.5.2 Debian package development tools ii file 5.03-3 Determines file type using "magic" ii html2text 1.3.2a-14 advanced HTML to text converter ii man-db2.5.6-4on-line manual pager ii perl 5.10.1-8 Larry Wall's Practical Extraction ii perl-base 5.10.1-8 minimal Perl system ii po-debconf1.0.16 tool for managing templates file t debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make(no description available) -- no debconf information -- see shy jo signature.asc Description: Digital signature
