Re: Official Exim 4 package
On Mon, Mar 24, 2003 at 04:36:17AM -0800, Steve Lamb wrote:
> On Sat, 22 Mar 2003 20:49:43 -0600
> "Jamin W. Collins" <jcollins@asgardsrealm.net> wrote:
> > Matter of preference. There are a number of packages in Debian with
> > their version (or some other indication of their version) in their name
> > already.
>
> Yes, it is a matter of preference.
Actually, it's not really. It's a matter of making things work.
> However, since when was preference a matter of /policy/. I am
> pointing out that there appears to be no policy in regards to when a
> version number is attached to the name of the package. The problem is
> that we now have packages which just the name works (sylpheed-claws)
> and other packages where one needs to include the version number to
> the major number (bind9) and others to the minor or revision
> (libssl0.9.7).
There is a manifestly clear policy on shared libraries. Shared library
packages must include the soname's version number, for good reasons.
When you understand those reasons it becomes clear why package names
sometimes have to change over major breaks in compatibility; it's a
simple extension in a looser way of the rules for shared libraries.
Finding package names is a job for package management front-ends, which
should include a search facility. If you're not using a front-end, you
already have problems in that you're probably ignoring Recommends: and
Suggests: hints provided by maintainers to try to make their packages
work better for you.
> My beef is that we already have a place for version numbers. Here:
>
> Package: libssl0.9.7
> Status: install ok installed
> Priority: standard
> Section: libs
> Installed-Size: 4801
> Maintainer: Christoph Martin <christoph.martin@uni-mainz.de>
> Source: openssl
> Version: 0.9.7-4
> ^^^^^^^^^^^^^^^^
Please go and understand why shared libraries need to include the soname
version in their package name, and then come back. If the version is
removed from the package name upgrades (certainly partial upgrades)
*will* break badly. And no, it's not particularly a hack: allowing
concurrent installation of multiple versions of a single package would
be much worse.
> Obviously there is a problem where some packages are breaking
> configuration compatibility and a way to keep two separate versions around
> without upgrading from one to the other happens often enough it needs to be
> addressed. However I don't think simply adding the version number into the
> package name is appropriate since the problem is in how the Version field is
> handled. It is a hack to get it to work. It isn't a hack to base policy of
> future compatibility on.
Well, if you feel like rewriting dpkg from the ground up (yes, your
ideas *will* require that) and making sure you can handle full
inter-release upgrades and partial upgrades correctly, feel free. Until
then we need to stick with what we've got, which is working pretty well.
> That is unless, of course, I am mistaken that there is some policy to
> cover this. If there is I'd be interested in someone pointing it out to me
> and explaining why we have packages without version numbers, packages with
> only majors and packages with major, minors and revisions in the name. I see
> no consistency which points to a well-written policy on the subject.
Package names change when it is necessary. Apart from the policy on
shared libraries I don't think there's any particular policy on this,
because we don't need one. Let me repeat: package names change when it
is technically necessary to do so in order to ensure the correctness of
upgrades, both complete and partial.
The lack of consistency does not point to a lack of policy. It points to
the complexity of making partial upgrades work, and the variety of
exciting ways in which packages sometimes break compatibility (library
APIs, configuration files, input file formats, etc.) with previous
versions of themselves.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: