Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
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.
Should a package manager really follow the Replaces? This would mean
we could end up removing A because A-doc replaces it? 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?
> 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…
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…
Best regards,
David Kalnischkies
Reply to: