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
Attachment:
signature.asc
Description: Digital signature