Re: Official Exim 4 package
On Mon, Mar 24, 2003 at 08:58:25AM -0800, Steve Lamb wrote:
> On Mon, 24 Mar 2003 16:04:04 +0000
> Colin Watson <cjwatson@debian.org> wrote:
> > There is a manifestly clear policy on shared libraries. Shared library
> > packages must include the soname's version number, for good reasons.
>
> Which is about the only package I would say that it is needed for multiple
> reasons.
Shared libraries are not unique. They're just the most common and easily
identifiable case of a more general problem.
> > 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.
>
> Quite the contrary. I use front-ends and turn those blasted suggests and
> recommends off. How does the maintainer know what works better "for me"?
> They don't. If I want something I'll include it, thank-you-very-much, not
> stop trying to add more bloat to my system. Of course none of that has to do
> with the problem at hand.
That has nothing to do with turning them off; they're just user
interface hints, not requirements. (In earlier versions of dselect a
Recommends: was effectively a requirement, but not any more.)
And I stand by my statement that you are choosing to lose information by
ignoring these hints: take vim's former recommendation of vim-rt, for
instance, or one of the X packages' recommendations of xfonts-base. Of
course you're free to ignore them if you want, but stop trying to claim
that they're some kind of encroachment on your liberty, which is just
absurd.
Incidentally, why are you trying to rearrange lots of rather
set-in-stone interfaces in order to fix one thing you see as a user
interface problem for finding packages, while railing against other
provisions we've made to help users find packages? I genuinely don't
understand this attitude.
> > And no, it's not particularly a hack: allowing concurrent installation of
> > multiple versions of a single package would be much worse.
>
> Uh, who said anything about concurrent installations of multiple versions.
> I said multiple /listings/ of the same package but different versions.
> Obviously if there is a compatibility issue they would have a conflict set up
> in the field named "Conflicts".
Ah, you think packages can conflict sanely with themselves, or that this
even makes sense given our clearly defined and relied-upon-in-packages
semantics for conflicts (discounting the special case where a package
conflicts with a virtual package it itself provides). I see.
Package: a
Version: 1.0
Depends: b (>= 1.0)
Package: b
Version: 1.0
Package: b
Version: 2.0
Conflicts: b (<< 2.0)
Now explain, based on the specifications for Depends: and Conflicts: in
the policy manual, why the Conflicts: ought to have any effect, and why
a's versioned dependency on b is not satisfied by b 2.0.
> I just love it when people read more into my words than I wrote there.
> Makes me all warm and fuzzy knowing they seem to think they know what I am
> thinking more than I am. Especially when what I wrote was quite clear.
One of the very good reasons why package names change is, in some cases
(although not all), to ensure that multiple versions of the package can
be installed concurrently in order to simplify upgrades: shared
libraries are a good example of this, but not the only one. It seems as
if you didn't know this, which is kind of scary in someone proposing
such major changes. I assumed that you did know this and would have
thought about this problem.
Also, my "quite clear" understanding of the packaging system as a
maintainer is that the existence of a Conflicts: implies that the two
conflicting packages (or versions of packages in your conception) might
otherwise be concurrently installed. I can't see any possible point to a
Conflicts: otherwise.
7.3. Conflicting binary packages - `Conflicts'
----------------------------------------------
When one binary package declares a conflict with another using a
`Conflicts' field, `dpkg' will refuse to allow them to be installed on
the system at the same time.
(debian-policy in woody)
If I'm reading things into your words at all, I'm basing it on
inferences from how I know the packaging system works, not on some kind
of prejudice.
> > 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.
>
> Why would it require a rewrite from the ground up? I'm betting it is
> based on your false presumption that I meant having two installed versions
> when I clearly meant to versions available in the repository and listed in the
> package manager with conflicts against each other.
Only partly. Consider an upgrade of package X that breaks compatibility,
where other packages depend on package X and need to be updated due to
the change in order to continue working at all. Now consider the partial
upgrade case where somebody decides to upgrade only package X (using
dpkg, perhaps not even downloading a new Packages file).
> Hell, we're 99% there or
> is aptitude lying to me?
>
> i --\ sylpheed-claws 0.8.10claws0.8.10claws
> i 0.8.10claws13-1
> p 0.7.4claws-3
>
> Two versions of the same package listed in the package manager. Granted,
> from two different repositories but it seems like most of the logic is already
> there. I select one, the other is marked for uninstall.
That's nowhere near close to all the logic that's required, and the
logic needs to be in all packages, not the packaging system. The above
looks to me like a result of multiple versions appearing from apt's
policy engine, but I'm talking about dpkg, not apt. dpkg considers
package names to be unique at a very fundamental level.
> > 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.
>
> Which leads us to a morass of problems on the user end when expected
> packages are not immediately obvious because of an inconsistency in the naming
> convention.
Learn to search. Sorry, but I can put this in no more polite way. It's
really not difficult, and due to other reasons (e.g. Perl package naming
policy, name clashes, etc.) the Debian package name won't necessarily be
the same as the upstream package name anyway.
Your suggestion is not just a matter of "we have the source, so let's
change it". It's a fundamental change requiring major changes in Debian
policy and a large amount of effort across a large number of the
packages in the Debian archive, and even if the necessary semantics
could be specified unambiguously and robustly it would take years to
deploy due to the problems surrounding inter-release compatibility - all
for a minor user interface issue that can easily be dealt with in
package management front-ends. It is not clear to me whether exim/exim4
requires a package name change, but it is definitely crystal-clear to me
that many cases do exist where it is necessary.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: