Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/30 Ludovic Brenta <ludovic@ludovic-brenta.org>:
> 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.
(I thought of this one while writing it but want to be a bit more generic:)
apt currently Replaces manpages-pl because it includes now the polish
translation of its manpages itself.
Is apt with this Replaces now a valid upgrade path for manpages-pl?
Even (or especially) if only manpages-pl is installed on the user system?
The Replaces says that if i upgrade apt i should at least try to upgrade
manpages-pl before (if it is installed) to get right of the Replaces -
it doesn't say that if i have manpages-pl installed i should install apt now
as well as it doesn't say that i should install manpages-pl if i have apt
installed. If i want that i need a Depends…
> 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.
If aptitude hasn't changed its complete logic recently it will behave as apt
and will never allow a user to move from a consistent into an inconsistent
state, so either your words are misleading, i don't understand you or both.
A package is not broken out of a sudden for a package manager.
Either the install candidate of another package Breaks it, Conflicts with it
or its dependencies in the candidate version are not satisfiable. A in this
way "broken" package* is either kept (by not installing the other packages),
upgraded (if dependencies allow it) or removed (if installing the other
packages is considered more important than the install status of this package)
These options are present and a package manager will chose one of
those depending on how costly they are. If the remove of package A
causes e.g. the remove of thousand other packages
it is likely that A will be kept back instead.
* It is only broken if the package manager would choose to upgrade
regardless of the outcome.
Its complete unrelated if the functionality of the package is broken.
This can happen, and this need to be modeled with dependencies
(Breaks and to a lesser extend Conflicts is what you want)
as otherwise the package manager will not know about it.
It (=the manager) can't follow rules it doesn't know…
> and, of course, Depends: on the exact version of A, i.e.
>
> Package: A-doc
> Depends: A (=2)
I hope not as it would be broken for all binary non-maintainer uploads of A…
And the Depends is at least questionable even without a version number
(many *-doc packages don't depend on anything. And if they do the
Depends is completely unrelated or extreme relaxed, only a small subset
does it like you suggest it).
Give it a try yourself:
apt-cache show $(apt-cache search ^.*-doc$ --names-only | cut
--delimiter=' ' -f 1 | sort -R | head -n 50) | grep -e 'Package: ' -e
'Depends: '
> 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.
I don't know anything about Ada and i don't have read the policy for
it as i will not understand it because of that - but even if i would read it
it doesn't change the dependencies written down - at least as long you
haven't told all package managers like dpkg, apt and aptitude to read and
understand your policy as well. Thats why i response here, i just
want to help you understand what a package manager will do with your
dependencies and that is independent from the content of the package.
In the end you will need to write dependencies even a crappy piece of
code can understand and at least for me it would be an indicator if
even humanoid dependency solvers can't understand them…
(Also, while a policy is free to declare that white is the new black
it is a good idea to follow established rules and just say black.)
Best regards,
David Kalnischkies
Reply to: