Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies <kalnischkies+debian@gmail.com> writes:
> 2010/5/29 Ludovic Brenta <ludovic@ludovic-brenta.org>:
>> David Kalnischkies <kalnischkies+debian@gmail.com> writes:
>>> No. Replaces is used to say to dpkg: It is okay that this package
>>> overrides files of the other package - otherwise dpkg would complain
>>> loudly for good reasons. It doesn't say something about the
>>> upgrade path.
>>
>> I disagree with this particular part of your analysis. What you say is
>> true of Conflicts, not of Replaces. IMHO, Replaces really, clearly
>> suggests an upgrade path. Why else would the package renaming procedure
>> require both Conflicts and Replaces?
>
> Consider a package A which moved from a bad example-config file to
> a full blown doc translated to 100 languages. The documentation is split
> out into a new package A-doc which will Replaces the old A version
> as it will override the "old" example-file. The A-doc package will end up as
> a Recommends or Suggests for A as it is not strictly needed to work with A.
This example is wrong.
Suppose package A (=1) contains /usr/share/doc/A/examples/config; the
successor is A-doc (=2) which contains
/usr/share/doc/A-doc/examples/config. There is no file conflict and no
need for Conflicts: or Replaces:. Now, just to make the example more
twisted, suppose the new A-doc contains a symlink:
/usr/share/doc/A-doc -> A
and, of course, Depends: on the exact version of A, i.e.
Package: A-doc
Depends: A (=2)
(per Debian Policy in such cases). Then there is still no conflict and
no need for Conflicts: or Replaces: because A-doc can never be installed
at the same time as the old A.
> Should a package manager really follow the Replaces?
I think so, yes.
If I take the trouble to specify Replaces, I mean it. If I do *not*
want the package manager to follow the Replaces, then I specify
Conflicts but *not* Replaces. Why else do we have two different
relationships?
> This would mean we could end up removing A because A-doc replaces it?
No, per my explanation above; instead, the package manager would install
the new A and the new A-doc.
> Or get full blown documentation - now that you have used the
> application for years without looking at the (non existing)
> documentation so far… You can construct for Conflicts a similar (and
> better) situation, 'extra' packages for example can Conflicts/Replaces
> with each other without any problems…
>
> Both together doesn't indicate much as well:
> Your installed mail-transport-agent conflicts+replaces all other MTAs.
> Is installing exim4 instead of postfix really an upgrade path?
I do not think mail-transport-agents should necessarily Replace each
other. They should only Conflict with each other.
>> Let me emphasize again that, for Ada, a new version of a -dev package
>> (i.e. libX2-dev) is *not* a complete replacement for libX1-dev,
>> therefore we must use neither a dummy transitional package nor a
>> Provides relationship.
>
> The question is why you want that people which have libX1-dev installed
> need to upgrade to libX2-dev AND remove libX1-dev by describing that
> only with dependencies in libX2-dev. It is simply not possible and
> doesn't make much sense:
> If libX1-dev can't be used anymore the package breaking it should
> "Breaks" it. If it is not broken why removing it?
> It will be autoremoved if it is not needed anymore…
The problem with -dev packages is that, usually, nothing depends on them
(apart for other -dev packages); they are only ever installed when a
user explicitly requests so, so aptitude will *not* autoremove them.
The consequence is that, despite the fact that these packages are broken
(without the need for a Breaks: in their successor packages, BTW),
aptitude prefers to leave them installed rather than remove them; this
in turn blocks upgrades.
> libX2-dev will be installed then something depends on it - or if the user
> needs it and requests it manually.
> I also don't see why libX1-dev and libX2-dev have Conflicts and/or
> Replaces on each other. Their naming _highly_ suggests
> that they can be co-installed and used. If they can't be co-installed
> and used why is the package not called libX-dev instead…
Please read the Debian Policy for Ada, to which I provided a link (at
least section 3.2 "Ada Library Information files". I mean it. If you
don't then you cannot possibly understand the problem.
--
Ludovic Brenta.
Reply to: