[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal for fixing automake (was Re: State of automake packages)



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: pgpEhtGCSJbPW.pgp
Description: PGP signature


Reply to: