Re: automake/autoconf in build-dependencies
On Sat, 19 Mar 2005, Henning Makholm wrote: > Better have them restricted to developers and users who modify code > than to have them happen randomly to people who just want to build the > unmodified package. Like, say, our security and QA teams. I would very much like their opinion on this, they're the ones that get to hold the short end of the stick when a maintainer fails to keep his package in top-notch condition. As far as I can see, any package that is not suffering bit-rot is much better off using a full autotools update per build, be it at every build (if you are a fan of dpatching the build structure), or at every source upload (if you'd rather do it under controlled conditions). That means the person who knows best (the package maintainer) AND who is supposed to be taking care of the package in the first place, keeps it working for everyone else. 99% of the time if something does not work with the latest autoconf (and latest *revision* of the automake branch used to create said package), it is buggy and bugs need to be fixed ASAP. Anything that does not work with the most up-to-date libtool and gettext needs to be fixed no later than a few weeks after sarge is out. I do not agree at all with your position that the best course of action is to allow a maintainer to be lazy and leave a stale build system around just so it is less trouble for him, at the detriment of everyone else. There are very, very few packages using auto* that are complex enough to warrant an "I am not touching this" policy re. the build system. We should consider them the exceptions for the rule, and keep everything else up-to-date. And really, I am one of those who call automake & friends "autohell", and libtool "libtrash" (which really is not deserved by libtool 1.5.6+, but the older versions... ugh). That said, I manage to not only take care of autotools-dev, but I have also converted *every* package of mine to the absolutest newest auto*, and managed to push it upstream 98% of the time (and for the package that did not make it upstream yet, it is actually much easier to maintain my fixed build structure than go with the outaded PoS upstream has). These are lessons well learned from the time fetchmail used to do hideous things because of whatever weird gettext ESR was using did not like a Debian system, a few years ago. -- "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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Scripsit Junichi Uekawa <[EMAIL PROTECTED]> >> > To a certain degree, those would have been fixed if people >> > build-depended on auto*, as they would have picked up fixed versions >> > of the .m4 files. >> But that has to be offset against the huge number of bugs that would >> occur if we ran auto* at run time and had everything break everytime >> the target moves. > That kind of bug will appear when a user tries to modify > other parts of the auto* files, and regenerate them. Better have them restricted to developers and users who modify code than to have them happen randomly to people who just want to build the unmodified package. -- Henning Makholm "However, the fact that the utterance by Epimenides of that false sentence could imply the existence of some Cretan who is not a liar is rather unsettling." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Hi, > > To a certain degree, those would have been fixed if people > > build-depended on auto*, as they would have picked up fixed versions > > of the .m4 files. > > But that has to be offset against the huge number of bugs that would > occur if we ran auto* at run time and had everything break everytime > the target moves. That kind of bug will appear when a user tries to modify other parts of the auto* files, and regenerate them. Even if we manage to ignore the problems on Debian build machines, users will find out that a source will not build, sometime. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Hi, > >The current practice and trend is going the other way, > >but I strongly recommend for using autoconf/automake in build scripts. > Does cdbs do it right? I've looked at the source of cdbs, and I figure that users of cdbs can configure and set variables: DEB_AUTO_UPDATE_LIBTOOL DEB_AUTO_UPDATE_AUTOCONF DEB_AUTO_UPDATE_AUTOMAKE DEB_AUTO_UPDATE_ACLOCAL So the users are given the option of re-generating auto* stuff. BTW, I'm a bit worried about auto-generating debian/control with cdbs; it will regenerate debian/control at build-time, which will make information in 'Sources.gz' obsolete and less useful. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > This only works because dpkg-buildpackage calls the clean target before > doing anything, BTW. And all things Debian follow its lead (i.e. pbuilder, > the buildds, sbuild, cvs-buildpackage, etc all either use dpkg-buildpackage > or do things as dpkg-buildpackage would do). And that is the key piece of information I had missed. The clean target runs before the diff.gz is created. That makes many things easy. >> If the Debian maintainer has run autotools before uploading, should >> the buildds re-run the autotools or not? > > They need not to IMHO, but if you want them to, you can easily force that to > happen as well. I would only do that if I needed to dpatch configure.ac, > or something like that. > >> > Agreed. That's the current best practice for Debian, as far as I am >> > concerned. > > I should have added that doing it at build time if you have a good reason to > is also best-practice. > >> README.Debian.gz is a little obscure in places, and answers to the >> above questions would be helpful to me. > > Sure thing. Did the above answers help any? Yes. Thanks! -- KBK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Hi, > >The current practice and trend is going the other way, > >but I strongly recommend for using autoconf/automake in build scripts. > > Does cdbs do it right? I've actually not looked into how cdbs handles things, so I cannot comment on it. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Scripsit Tollef Fog Heen <[EMAIL PROTECTED]> > * Henning Makholm > | When I provide a configure script in the source package it means, on > | the contrary, that I *have* tried it and therefore has some kind of > | evidence that it will probably work for other people too. > You have probably only tried it on one architecture. Which is why I wrote "some kind of evidence that it will probably work" instead of "know that it will work". > To a certain degree, those would have been fixed if people > build-depended on auto*, as they would have picked up fixed versions > of the .m4 files. But that has to be offset against the huge number of bugs that would occur if we ran auto* at run time and had everything break everytime the target moves. -- Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
* Henning Makholm | When I provide a configure script in the source package it means, on | the contrary, that I *have* tried it and therefore has some kind of | evidence that it will probably work for other people too. You have probably only tried it on one architecture. A lot of the bugs I see as a porter are of the type «something in $foo's configure script didn't pick up $bar, which breaks spectacularly somewhere later». Stuff like #175491 which made evolution(!) with a SIGFPE before main or _init. To a certain degree, those would have been fixed if people build-depended on auto*, as they would have picked up fixed versions of the .m4 files. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
On Mon, Mar 14, 2005 at 01:18:12AM -0500, Kurt B. Kaiser wrote:
> Machine generated files (e.g. configure) constructed by autotools
> should not be in CVS.
> However, these files (as generated by the Debian maintainer's autotools
> run before the upload) should be included in the source package via the
> .diff.gz. so that the user doesn't need autotools.
> Therefore, the Debian maintainer should run autotools using current
> config.{sub,guess} before the diff.gz file is generated, possibly via
> an 'autogen.sh' script.
I think you got this last big backwards. config.{sub,guess} are used by
the configure script, not autoconf. So you can run autoconf at
package-source creation-time, and still gain the benefits of current
config.{sub,guess} at package (re)build-time. In fact, I believe that
was the original motivation for autotools-dev, since config.{sub,guess}
needed to be updated due to the fluidity of some ports (I think the
mips, sh and BSD ports were/are the most common "FTBFS: Update
config.{sub,guess}", but I could be wrong.)
--
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---
signature.asc
Description: Digital signature
Re: automake/autoconf in build-dependencies
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>> When I include the configure script in my source packages, I can feel
>> pretty confident that they package I upload will stay buildable even
>> if a week from now autoconf or automake gets updated to something not
>> backwards compatible.
>
> Yes. That's how I see it as well.
As I understand your suggestions in autotools-dev:
Machine generated files (e.g. configure) constructed by autotools
should not be in CVS.
However, these files (as generated by the Debian maintainer's autotools
run before the upload) should be included in the source package via the
.diff.gz. so that the user doesn't need autotools.
Therefore, the Debian maintainer should run autotools using current
config.{sub,guess} before the diff.gz file is generated, possibly via
an 'autogen.sh' script.
The README.Debian.gz from autotools-dev states:
===
"One can either get this script [i.e. autogen.sh] to be run by
configuring CVS to do so, or by adding some Makefile rules in
debian/rules.
Do note that a properly done autogen.sh invocation runs before dpkg
has a chance to build the source package, so as to make sure an user
does NOT need any of the programs called by autogen.sh to build the
package. This will, in fact, ease the load on auto-builders as well
since the program will build much faster."
===
1. How does one configure CVS to run the autogen.sh?
2. If the autogen.sh invocation is done during the build by
debian/rules it can't be done prior to "building the source
package", which I interpret to mean creating the .diff.gz. "Get
this script to be run" implies a dependency of some kind: a missing
configure script or a missing configure-stamp. And in that case,
the buildds will also invoke it.
3. When using cvs-buildpackage, a clean copy of the repository is
exported, but then dpkg-buildpackage kicks off without a chance for
maintainer intervention to do something before the build. Perhaps
I could use the -H option to run autogen.sh?
>> > - The extra space in the diff.gz expands the size needed on every
>> > single Debian mirror, as opposed to the short one-time penalties on a
>> > few buildd's.
>
> Unfortunatelly, it is still a good tradeoff. I am not even bothering about
> CPU time in the buildds anymore, since I got told by buildd admins and
> porters a number of times not to. BUT the long-term package quality
> benefits are worth the increase in space.
If the Debian maintainer has run autotools before uploading, should
the buildds re-run the autotools or not?
>> That's a real issue, but I still think the least bad solution is to
>> ship finished, known-to-work build scripts in the source package.
>
> Agreed. That's the current best practice for Debian, as far as I am
> concerned.
>
> In fact, best practice for Debian also requires that you use
> config.sub and config.guess from autotools-dev if your configure
> script needs them. Just a shameless plug for autotools-dev :-)
README.Debian.gz is a little obscure in places, and answers to the
above questions would be helpful to me.
--
Thanks, KBK
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
On Mon, 14 Mar 2005 09:04:17 +0900, Junichi Uekawa <[EMAIL PROTECTED]> wrote: >The current practice and trend is going the other way, >but I strongly recommend for using autoconf/automake in build scripts. Does cdbs do it right? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: automake/autoconf in build-dependencies
On Mon, 14 Mar 2005, Kurt B. Kaiser wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > >> When I include the configure script in my source packages, I can feel > >> pretty confident that they package I upload will stay buildable even > >> if a week from now autoconf or automake gets updated to something not > >> backwards compatible. > > > > Yes. That's how I see it as well. > > > However, these files (as generated by the Debian maintainer's autotools > run before the upload) should be included in the source package via the > .diff.gz. so that the user doesn't need autotools. OR, if you have a damn good reason to (e.g. you dpatch configure.ac), you run autotools on the build tree... > 1. How does one configure CVS to run the autogen.sh? Module hooks in CVSROOT/* stuff. I never did that, I prefer to have debian/rules run autogen.sh if configure is missing. > 2. If the autogen.sh invocation is done during the build by >debian/rules it can't be done prior to "building the source >package", which I interpret to mean creating the .diff.gz. "Get >this script to be run" implies a dependency of some kind: a missing >configure script or a missing configure-stamp. And in that case, >the buildds will also invoke it. No, they won't. See all the build logs for all my packages that build-depend on autotools-dev for empiric proof. In particular, get rng-tools which is a small one and fairly simple to understand, and play with it. > 3. When using cvs-buildpackage, a clean copy of the repository is >exported, but then dpkg-buildpackage kicks off without a chance for >maintainer intervention to do something before the build. Perhaps >I could use the -H option to run autogen.sh? There is no need to. configure is missing, so make will run autogen.sh which will create it. This only works because dpkg-buildpackage calls the clean target before doing anything, BTW. And all things Debian follow its lead (i.e. pbuilder, the buildds, sbuild, cvs-buildpackage, etc all either use dpkg-buildpackage or do things as dpkg-buildpackage would do). > If the Debian maintainer has run autotools before uploading, should > the buildds re-run the autotools or not? They need not to IMHO, but if you want them to, you can easily force that to happen as well. I would only do that if I needed to dpatch configure.ac, or something like that. > > Agreed. That's the current best practice for Debian, as far as I am > > concerned. I should have added that doing it at build time if you have a good reason to is also best-practice. > README.Debian.gz is a little obscure in places, and answers to the > above questions would be helpful to me. Sure thing. Did the above answers help any? -- "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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Hi, > However, if I left it to the source package to run autoconf by itself > weach time it is build, it could slide into unbuildability _without me > or anybody else noticing_ before it is too late and we have > not-buildable-anymore code sitting around in the archive, and most > likely even in testing. IMO, it should be the other way around; it will slide into unbuildability without anybody noticing if we don't auto-generate using autoconf and automake. People do rebuild Debian packages regularly. By autogenerating autoconf/automake data at build time it is possible to ensure that users can edit configure.ac and Makefile.am safely. It will better serve users to notice autoconf/automake incompatibility earlier than when trying to modify the source. The current practice and trend is going the other way, but I strongly recommend for using autoconf/automake in build scripts. regards, junichi pgpjd1I92BS0L.pgp Description: PGP signature
Re: automake/autoconf in build-dependencies
On Thu, 2005-03-10 at 12:05 -0600, Adam Heath wrote: > On Fri, 11 Mar 2005, Paul Hampson wrote: > > > * timestamp skew means that the autobuilt makefiles will try > > to rebuild configure from configure.in even if configure is patched by > > dpkg-source at the same time as configure.in > > * A solution for this is in the above-mentioned README.Debian > > New dpkg-source support will work too. > Really? Perhaps you'd like to share your ideas and/or code with people who've actually touched dpkg in the last 18 months? debian-dpkg@lists.debian.org or www.dpkg.org, in case it's been so long that you've forgotten. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: automake/autoconf in build-dependencies
Scripsit Kurt Roeckx <[EMAIL PROTECTED]> > Or are you saying that all build dependencies should be removed, > since they all can cause you problems. I am saying that this particular build dependency can be removed without causing problems that have anywhere near the severity of the problems that can be avoided by removing it. I am not stupid enough to claim that this applies to all build-dependencies, so I am not going to play strawman to the rest of your "argument". -- Henning Makholm"Jeg køber intet af Sulla, og selv om uordenen griber planmæssigt om sig, så er vi endnu ikke nået dertil hvor ordentlige mennesker kan tillade sig at stjæle slaver fra hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."
Re: automake/autoconf in build-dependencies
Hi Kurt, On Sun, Mar 13, 2005 at 03:40:23PM +0100, Kurt Roeckx wrote: > > That's the point, actually: If I build-depend on autoconf, I *cannot* > > know that it will actually build after the next update to autoconf, > > because most likely nobody will try it. > > If it's known that a new major version of autoconf is uploaded to > the archive that might break some packages, it's rather easy to > see which packages build depend and you can very if they still > work or not. This goes for all build dependencies for a package. Great. And while most people continue telling that it is always easy to fix autoconf breakage that is not always true. I am using autoconf and automake for my own programs but they are hardly as complicated as for example the OpenLDAP autoconf setup. I am glad the I can create a configure script with autoconf2.50 for OpenLDAP but upstream still is at 2.13 and seems not likely to update. Which is a lot of fun if you need current libtool etc. Basically as long as it works don't even think about touching it. Much less if upstream is not going to accept your changes. > Also, there are some people (including me) who rebuild the whole > archive regularly (but uncoordinated) to look for pacakges that > no longer build. There are more things than just autoconf > updates that make packages suddenly fail to build. ... but we are discussing autoconf now. Surely something else can break as well but this is not a reason to say "okay, one more weak spot". > Or are you saying that all build dependencies should be removed, > since they all can cause you problems. Maybe you want to have > everything your packages requires to build in your .orig.tar.gz > file? Including things like all headers from libc and gcc. You > know, gcc might change some day and your package might no longer > build because it's more strict about some things, maybe you > should also include your own copy of gcc in it for all arches. There is a C standard. If the program does not conform to it it is broken. There is no autoconf standard. autoconf is a moving target. > I find the argument that it might break some time because of new > version your package build depends on a bad reason. Where > does that stop? Some packages for instance have their own > copy of libz or gettext included. I find that a bad thing, they > should all be changed to build depend on the packages that > provide it and not use the included version if possible. There > are several reasons why you want that, one of them being that > it's alot easier to have all packages fixed if there is a > security bug found in one of those packages. You are right. But until upstream supports that it is often easier to go with the upstream choice. We all know there are a lot of things we'd rather have changed for the better. But in the end the user wants current and working packages. And if I can save some time by putting generated configure scripts into my packages I will do that and carry on. Greetings Torsten signature.asc Description: Digital signature
Re: automake/autoconf in build-dependencies
On Sun, Mar 13, 2005 at 02:02:29PM +, Henning Makholm wrote: > Scripsit Kurt Roeckx > > > And how can you know you can actually build it if you > > never tried it? > > That's the point, actually: If I build-depend on autoconf, I *cannot* > know that it will actually build after the next update to autoconf, > because most likely nobody will try it. If it's known that a new major version of autoconf is uploaded to the archive that might break some packages, it's rather easy to see which packages build depend and you can very if they still work or not. This goes for all build dependencies for a package. Also, there are some people (including me) who rebuild the whole archive regularly (but uncoordinated) to look for pacakges that no longer build. There are more things than just autoconf updates that make packages suddenly fail to build. Or are you saying that all build dependencies should be removed, since they all can cause you problems. Maybe you want to have everything your packages requires to build in your .orig.tar.gz file? Including things like all headers from libc and gcc. You know, gcc might change some day and your package might no longer build because it's more strict about some things, maybe you should also include your own copy of gcc in it for all arches. I find the argument that it might break some time because of new version your package build depends on a bad reason. Where does that stop? Some packages for instance have their own copy of libz or gettext included. I find that a bad thing, they should all be changed to build depend on the packages that provide it and not use the included version if possible. There are several reasons why you want that, one of them being that it's alot easier to have all packages fixed if there is a security bug found in one of those packages. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Scripsit Kurt Roeckx > And how can you know you can actually build it if you > never tried it? That's the point, actually: If I build-depend on autoconf, I *cannot* know that it will actually build after the next update to autoconf, because most likely nobody will try it. When I provide a configure script in the source package it means, on the contrary, that I *have* tried it and therefore has some kind of evidence that it will probably work for other people too. -- Henning Makholm "That's okay. I'm hoping to convince the millions of open-minded people like Hrunkner Unnerby." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
On Sun, Mar 13, 2005 at 12:04:59PM +, Henning Makholm wrote: > Scripsit Daniel Schepler <[EMAIL PROTECTED]> > > > - Putting autoconf-generated files in the source package is nearly as > > fragile as generating them at build time. If there are changes in > > autoconf which break the configure.ac etc, then the next time you want > > to make other changes or bring your changes forward to a new upstream > > version, you'll have to fix things anyway. This to my mind pretty > > much reduces the "future buildability" benefits to nearly nothing. > > That's a reason *contra* in my opinion. > > When I include the configure script in my source packages, I can feel > pretty confident that they package I upload will stay buildable even > if a week from now autoconf or automake gets updated to something not > backwards compatible. Some arches for instance have problems with old versions of libtool resulting in a broken configure on only those arches. Now they have to file a bug report asking for a libtool update to the latest (debian) version. It _could_ be handy that such requests weren't needed. Note that I do understand your argument that a new version could break. But we do have autoconf, autoconf2.13, automake1.4, automake1.6, automake1.7, automake1.8, automake1.9, libtool, libtool1.4. You can build-depend on the version that you require. However, I do understand that if you just build-depend on autoconf and you suddenly have to change to autoconf2.13 because they changed the version to 2.5x and your script doesn't work with autoconf 2.5x you have a problem. But sooner or later you will have to do something about the problem anyway. You can't stay using autoconf2.13 for ever. Some day that version will get removed from the archive. Just like libtool1.4 is already orphaned and planned to be removed after sarge gets released. An other argument that was only vaguely mentioned was that you can look at configure.in/ac as source. Some people seem to disagree with this but I haven't seen their arguments for it. I don't think I can agree to their arguments anyway. The same goes for things like bison. We do not have a requirement that everything is build from source, only that we should be able to do so. But I think it's a good idea to always build everything from sources. If you have to fix something, it's always going to be easier to fix in the source. And how can you know you can actually build it if you never tried it? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
On Sun, 13 Mar 2005, Henning Makholm wrote: > Scripsit Daniel Schepler <[EMAIL PROTECTED]> > > - Putting autoconf-generated files in the source package is nearly as > > fragile as generating them at build time. If there are changes in > > autoconf which break the configure.ac etc, then the next time you want > > to make other changes or bring your changes forward to a new upstream > > version, you'll have to fix things anyway. This to my mind pretty > > much reduces the "future buildability" benefits to nearly nothing. Experience tells me you are wrong. > When I include the configure script in my source packages, I can feel > pretty confident that they package I upload will stay buildable even > if a week from now autoconf or automake gets updated to something not > backwards compatible. Yes. That's how I see it as well. > > - The extra space in the diff.gz expands the size needed on every > > single Debian mirror, as opposed to the short one-time penalties on a > > few buildd's. Unfortunatelly, it is still a good tradeoff. I am not even bothering about CPU time in the buildds anymore, since I got told by buildd admins and porters a number of times not to. BUT the long-term package quality benefits are worth the increase in space. > That's a real issue, but I still think the least bad solution is to > ship finished, known-to-work build scripts in the source package. Agreed. That's the current best practice for Debian, as far as I am concerned. In fact, best practice for Debian also requires that you use config.sub and config.guess from autotools-dev if your configure script needs them. Just a shameless plug for 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
Scripsit Daniel Schepler <[EMAIL PROTECTED]> > - Putting autoconf-generated files in the source package is nearly as > fragile as generating them at build time. If there are changes in > autoconf which break the configure.ac etc, then the next time you want > to make other changes or bring your changes forward to a new upstream > version, you'll have to fix things anyway. This to my mind pretty > much reduces the "future buildability" benefits to nearly nothing. That's a reason *contra* in my opinion. When I include the configure script in my source packages, I can feel pretty confident that they package I upload will stay buildable even if a week from now autoconf or automake gets updated to something not backwards compatible. The next time I upload I am going to either reuse the working configure script from the previous package (if I'm managing things by hand) or try to generate a new one with the tools I have available by then (if I'm using cvs-buildpackage or one of its equivalents). In the latter case, if anything stops working I will _find out_ before I upload, both because I have to run the script myself as part of building and because as a matter of course I run debdiff to compare with the latest version before I upload. However, if I left it to the source package to run autoconf by itself weach time it is build, it could slide into unbuildability _without me or anybody else noticing_ before it is too late and we have not-buildable-anymore code sitting around in the archive, and most likely even in testing. > - The extra space in the diff.gz expands the size needed on every > single Debian mirror, as opposed to the short one-time penalties on a > few buildd's. That's a real issue, but I still think the least bad solution is to ship finished, known-to-work build scripts in the source package. -- Henning Makholm "Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
[EMAIL PROTECTED] (Paul Hampson) writes: > The arguments _for_ build-depending on the various autotools are (off > the top of my head) Here are some other reasons pro that I can think of: - Putting autoconf-generated files in the source package is nearly as fragile as generating them at build time. If there are changes in autoconf which break the configure.ac etc, then the next time you want to make other changes or bring your changes forward to a new upstream version, you'll have to fix things anyway. This to my mind pretty much reduces the "future buildability" benefits to nearly nothing. - You automatically get bug fixes in autoconf. (Minor, and not worth doing it for this alone, imho.) - The extra space in the diff.gz expands the size needed on every single Debian mirror, as opposed to the short one-time penalties on a few buildd's. And I heartily agree with the argument concerning making diff.gz's readable. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
[EMAIL PROTECTED] (Paul Hampson) writes:
> The arguments _for_ build-depending on the various autotools are (off
> the top of my head)
>
> (In the below, read autoconf as autoconf/automake. ^_^)
>
> * keeps .diff.gz small and readable, as configure changes are
> not included. And small configure.in changes cascade into many
> configure changes
> * This is a maintainer decision, really. Not _wrong_ per se.
>
> * timestamp skew means that the autobuilt makefiles will try
> to rebuild configure from configure.in even if configure is patched by
> dpkg-source at the same time as configure.in
> * A solution for this is in the above-mentioned README.Debian
Once more autobuilders switch to 2.6 kernels this will happen even
more often. Till now a lot of buggy sources just got lucky during
build.
> * Upstream distributes without generated files (eg. CVS pull)
> or with generated files using older or buggier versions of the
> autotools.
> * In this case, pristine source tarball means pre-autoconf,
> and the maintainer again wants to keep the .diff.gz small.
Personaly I prefer the autotools-dev solution with proper timestamp
fixes in debian/rules. That means that the package will be build with
the same scripts on all hosts except for config.{guess,sub}. That is
most likely to succeed.
Second place is sources with a Build-Depend on automake/autoconf and
no generated files in the source. That avoids timestamp skews even
when a buildd is a few timezones in the past compared to the upload.
Anything else fails randomly.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
On Fri, 11 Mar 2005, Paul Hampson wrote: > * timestamp skew means that the autobuilt makefiles will try > to rebuild configure from configure.in even if configure is patched by > dpkg-source at the same time as configure.in > * A solution for this is in the above-mentioned README.Debian New dpkg-source support will work too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
On Thu, Mar 10, 2005 at 01:52:45PM +0100, martin f krafft wrote: > I have often tried to argue my position on automake/autoconf in > packages' build dependencies: I do not think they belong there. If > a package does not build without automake or autoconf, it is broken > and should be fixed. However, bugs like #298336 seem to suggest that > other maintainers deem it entirely appropriate to "go the easy way" > -- if I may call it that without being condescending towards Uwe. > I seem to recall the devel-reference or some similar document to > specifically address this issue, but I cannot find the location > anymore. I think you're thinking of /usr/share/doc/autotools-dev/README.Debian.gz > Thus I am interested in opinions of people who argue that > automake/autoconf are perfectly acceptable as build dependencies. > Also, are there technical arguments against these build > dependencies? I am too inexperienced with the GNU autotools to > come up with something. The arguments _for_ build-depending on the various autotools are (off the top of my head) (In the below, read autoconf as autoconf/automake. ^_^) * keeps .diff.gz small and readable, as configure changes are not included. And small configure.in changes cascade into many configure changes * This is a maintainer decision, really. Not _wrong_ per se. * timestamp skew means that the autobuilt makefiles will try to rebuild configure from configure.in even if configure is patched by dpkg-source at the same time as configure.in * A solution for this is in the above-mentioned README.Debian * Upstream distributes without generated files (eg. CVS pull) or with generated files using older or buggier versions of the autotools. * In this case, pristine source tarball means pre-autoconf, and the maintainer again wants to keep the .diff.gz small. > I am perfectly aware that there are (and should be) exceptions. For > instance, if a package should be made available sooner rather than > later, and the maintainer then sits down to work on the autotools > configuration to fix the bug for the next upload. However, this > always bears the danger that the maintainer then loses interest and > the archive will contain what I claim to be a broken source > package... even though it may well build. I'm not sure I'd consider a package that build-depends on autoconf to be _broken_ per se. I don't _believe_ this shows up anywhere in policy or otherwise that can make this a non-ignorable bug report for such a package. I welcome corrections on this point. I am particularly interested in an argument that spells out how this is broken, as opposed to "not neat in my opinion". I _do_ think it is a riskier way of dealing with a package, as I'm not sure what new features are expected to appear in autoconf that weren't in the version used at last build-time, that can be taken advantage of automatically. Surely a bugfix in autoconf would have either already caused a bugreport against the package, or have been irrelevant to the package itself? Certainly, this dubious benefit to my mind does not outweigh the risk of having a previously working build-environment suddenly break, as I vaugely recall happened when autoconf went from 2.13 to 2.53 and suddenly half of the Debian archive FTBFS. (Exaggeration used for effect. ^_^) I don't see how build-depending on autoconf etc could possibly speed up a package release, unless the maintainer is trying to move to a different autoconf version than upstream is using, and refuses to install the version upstream is using. (But is happy for the buildds to do so) In short, _I_ wouldn't do it, same as I wouldn't build-depend on flex and bison. I might not store their output in my CVS tree, but I wouldn't build-depend on them either. (And if anyone feels the need to ask me what this means in terms of 'What is source?' they get to stand between me and Andrew Suffield if I answer. ^_^) (This doesn't apply to config.sub and config.guess. I _do_ pull those at build-time, since _they_ sometimes need to be upgraded for different architectures. This is a different (controversial?) issue. ^_^) -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: automake/autoconf in build-dependencies
Scripsit martin f krafft <[EMAIL PROTECTED]> > I seem to recall the devel-reference or some similar document to > specifically address this issue, but I cannot find the location > anymore. Are you thinking about /usr/share/doc/autotools-dev/README.Debian.gz? -- Henning Makholm "They discussed old Tommy Somebody and Jerry Someone Else." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
