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.
> 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.
> 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".
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.
> 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. 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.
> 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. You mentioned that shared libs have that policy in place. IE,
there is a consistent naming convention. If the user knows to go into that
area looking for version numbers tacked into the end then there is no problem.
However there is a problem in the rest of the space because there is no
convention, no consistency.
> 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.
Which, as I said, is not an entirely uncommon problem. A problem which
should not be handled the way it is for the reasons described. Either all
packages should have version numbers or another way of handling the problem
which is transparent to the user needs to be devised.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
| -- Lenny Nero - Strange Days
-------------------------------+---------------------------------------------
Attachment:
pgp0JPwbG_MfU.pgp
Description: PGP signature