On Mon, Jun 10, 2002 at 03:03:21PM +0900, Junichi Uekawa wrote: > > It's compatibile for most things. There are a few thou-shalt-nots which > > cause the new version to be broken, but they're easily fixed in almost all > > cases. They just require someone to actually do the fixing. > > "Compatible for most things" and "it can be fixed up manually" > is not good enough :P Well we have this little problem you see... We can't control upstream. They fucked up, badly. But we can't undo their fuckup for them, and they seem uninclined to do it. Best we can do is fix things in Debian so that they work, regardless of which version of automake you use on them. > Really, a real solution would be to fixing things which build-depend on > "automake" to depend on "automake1.6" or "automake1.4" or whatever. I don't see the problem with an alternative of 20 vs 40 for 1.6 and 1.4 respectively. If you have automake1.6 only, it will probably work as automake if upstream has been taking care of their software. If not, well, install 1.4! I think that within Debian we should pick one and stick to it. Since 1.5 is now required for several things and anything which doesn't work with 1.5+ is regarded upstream as a bug, it's unreasonable for us to make that standard be 1.4.. But I don't think we can remove 1.4 either. No matter what we do inside Debian, the outside world will continue to do what it pleases. At least one project I know of does not work with 1.5+ and its author says hell will freeze before he updates to the new versions, since he considers them profoundly broken. As usual, Debian gets stuck cleaning up the mess. > Not dumping automake1.6 to be "automake". > > a) Dumping automake1.6 to be automake will require: > > 1. autobuilders (or me) noticing the problem > 2. autobuilders (or me) filing bugs on individual packages > 3. maintainers, or QA people (or me) fixing and uploading the package I have already proposed the solution to this problem. It involves: 1. Building a list of all packages in Debian which do not work with current versions of autoconf/automake, outside the BTS. 2. Interested developers fixing these packages to work with the current versions of autoconf/automake. 3. Package maintainers or those interested developers uploading new versions of the packages with patches applied. All of this should be done well in advance of any alternatives, autobuilder processing, or filing of bug reports. But it needs doing because at some point, when someone says you need automake, it will be expected that tey mean 1.6 or some later version. We cannot bury our heads in the sand on this one. > b) Changing the individual packages to build-depend on automake1.6 or > automake1.4 will require: > > 1. maintainers, or QA people (or you??) fixing and uploading the package This ignores the fact that we will need to have, essentially forever, two different and almost compatible versions of the same package. If a package does not work with 1.6, it needs fixing. That is all - it is a bug that we should treat like any other. However, given that this bug is completely upstream's fault, and given that there are developers willing to go through the entire distribution and fix these bugs now, that is precisely the correct solution. > When "automake" is pulled away, packages which still depend > upon automake should be obvious in b, while it won't be obvious > at all in a. > > a. is a more convoluted way of fixing the problem at hand. > b. is better in that it costs less for Debian Project as a whole, in total. Personally, I don't want to NEED automake1.4 in six months. And in about a year, I expect no excuse to even have it. Times change, software gets updated. Sometimes you like how it was updated, sometimes you don't. The rest of the world is getting on with life. Using your proposed non-solution, I can virtually guarantee that four years from now, when I finally get my fresh from the press Sarge CD set, I will need both a current and a long-since obsolete version of the same program because people will have concluded the build-depends on the old vs. new automake to be sufficient. We can fix that in a few weeks' time, largely without impacting the distribution at all until after the work has been done. Should we ignore this opportunity to address the problem before it ever becomes one? > Note that most packages won't be autobuilt unless some crazy > fanatic starts rebuilding the whole archive for the fun of it. > Which makes solution a less attractive. I've proposed that crazy fanatics begin doing so now, using automake1.6 as automake, to find out what breaks. This reduces the problem set to just those things which actually have a problem, clearly. There should not be many such packages, and even those of us on modems can make short work of these few things which break. -- Joseph Carter <knghtbrd@bluecherry.net> <-- That boy needs therapy <f00Dave> Look, rejects, this is #OpenGL, not #GEEKSEX.
Attachment:
pgpjlk1zdDtxo.pgp
Description: PGP signature