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

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



* Anthony Towns (aj@azure.humbug.org.au) wrote:
> On Sat, Jun 08, 2002 at 02:13:10AM -0400, Eric Dorland wrote:
> > > One possibility is to make "automake1.4.deb" be the only package that
> > > provides "automake", [...]
> > Yes, but that seems like a bit of an inelegant solution, since it is
> > possible for a package to want any automake, not necessarily
> > automake1.4. It is possible to write Makefile.am's that are portable
> > across all the current versions. 
> 
> Does that also mean they'll be portable to automake1.7, or is it just
> a coincidence that upstream haven't made incompatible changes for those
> particular features? (Bitter? Who, me?) I haven't looked at automake1.6,
> but if it doesn't conflict: with automake1.4, then presumably it doesn't
> provide /usr/bin/automake?

It is possible to write Makefile.am's that are portable across all the
current versions of automake. Quoting from the automake manual:

"New Automake releases usually include bug fixes and new
features. Unfortunately they may also introduce new bugs and
incompatibilities. This make four reasons why a package may require a
particular Automake version."
 
Which doesn't seem to say drastic things about breaking backwards
compatibility every release. Automake 1.6 provides a binary called
automake-1.6, because it is not backwards compatible with every
undocumented feature that worked in previous versions.

> > > There's probably no need for a dummy package -- they're only really
> > > useful when you're splitting a package.
> > Yes, but it might be nice for someone to do apt-get install automake
> > and get a nice version of automake installed. I realize that's
> > somewhat low priority, but it would still be nice :)
> 
> All you need for that is for "automake" to be provided by just one
> package.  But it's more important for the buildds to be able to do
> "apt-get install automake" and have the version that satisfies the
> build-dependencies correctly get installed.

Right, but right some packages depend on automake, when they really
mean automake1.4. If we renamed the current automake package
automake1.4, then have a dummy package that depends on automake1.4
until all the dependencies are fixed. Then the automake dummy package
can depend on the latest automake1.X package.

I understand what you mean by having only one package provide
'automake', and it would solve the problem. But its a bit of
deception, since all the automake1.X packages provide the ability to
'automake' style things.

-- 
Eric Dorland <dorland@lords.com>
ICQ: #61138586, Jabber: hooty@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
------END GEEK CODE BLOCK------

Attachment: pgpyICZKvb_iN.pgp
Description: PGP signature


Reply to: