On Thu Oct 02, 2003 at 12:47:50AM +0200, Buchan Milne wrote: > > > I don't believe there is anyone enjoying having to mantain 4 different > > > packages of the same software when one would suffice. > > > > Probably not. But if you, as a contributor, have a cooker machine and > > compile on cooker, how can you possibly know if your package, despite having > > conditional build macros, will work with an older distrib if you don't take > > the time to build and test on that old platform? So you *do* need to > > maintain it in such a manner otherwise you're just pumping out stuff that > > pretends to work on old distribs and you really don't have a clue if it does > > or not. > > But, the point is that if people are interested in maintaining their > packages for rebuild on older releases, then it may be possible to make > this easier by having automated rebuilds on stable releases.
Yes, but don't you understand that automatic rebuilds is not enough? It needs to be *tested* first. Man, I could automatically rebuild all kinds of stuff for updates but if I didn't test them first people would have fits! =) If you're going to update something for a stable release, you need to test it first. You can't just throw it in and wait for feedback. > I don't know if I can offer it, but we have a 150-machine (90 dedicated, > 60 dual-boot) lab running Mandrake 9.1 somewhere here at the university, > and we have a cooker mirror (that is usually not too far behind). It may > be feasible (depending on how much time I have available) to set up some > chroots on a machine on this network and use some or many of these for > automatic rebuilds. We wouldn't be able to host the binaries, but we could > probably host build output (ie slbd for stable releases). Build output is great, but if an app doesn't work and no one tries it, what good is it? Ie. on Corp 2.1/x86_64 apparently no one tried to do a search in joe... it segfaults every time. Now, granted, not too many people were able to test that (from my understanding) but a simple rebuild wouldn't have shown that as being a problem. rpmlint could be happier than sin, slbd could tell you nothing, but unless someone has written a program to fire up a program and fiddle with it automatically and then notify you if there is a problem or something doesn't operate properly *before* making it publically available, there isn't much point to an automatic rebuild. Auto rebuilds are great for cross-platform *current* development but trust me... they will absolutely cause nightmares for backporting to older releases. The point of opening up "updates for contribs" is not to provide people with junk that is auto-rebuilt. It's to provide people with an update which implies a) better functionality and b) stable, to go with the rest of the stable OS. Your offer, while grand, is of limited real value unless the developer can have some kind of elevated privileges to make sure that the server app they are rebuilding works or be able to sit in front of the machine in X to make sure their GUI app works. I completely 110% believe in this. I've been doing this for a lot of different software for three years and I know the little quirks that come when backporting newer stuff to older distribs. That is why I'm not building PPC updates on a machine in France; I have one here so that I can actually test it. That is why I am getting an opteron machine here... not just so that building is faster, but so that I can *test* everything before it goes out the door. We had problems with 8.1/ia64 because I did not have an ia64 machine here so everything that went out was virtually untested. It compiled, yes, but as we've seen with joe for Corp 2.1, while most of it worked, a criticial piece of it did not... There are things that a blind rebuild cannot take into account for. -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp00000.pgp
Description: PGP signature
