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