Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies wrote:
> 2010/5/30 Ludovic Brenta <ludovic@ludovic-brenta.org>:
>> 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.
I explained in my original post; please re-read it and then you will
understand. Hint: removal of gnat-4.3.
[...]
>> Package: A-doc
>> Depends: A (=2)
>
> I hope not as it would be broken for all binary non-maintainer uploads
of
> A…
You are correct; I really meant:
Package: A-doc
Depends: A (=${binary:Version})
> 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).
The Depends is mandatory in the one specific case that I described, i.e.
the -doc packages contains a symlink to a directory provided by another
package. Of course this is a minority of -doc packages. But my point
was to disprove your theory that a -doc packages needs to Conflict and
Replaces with a non-doc packages. It doesn't. Now let's drop that
part of the discussion.
[...]
>> 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
Yes, you will. If you are smart enough to understand dpkg, then you
are smart enough to understand this document. No knowledge of Ada is
necessary. Knowledge of dpkg is. If you refuse to read the document,
then take my word for it: the package name changes are necessary and
justified.
> - 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.
I do not ask that apt understand "my" policy. I ask that when a package
A Replaces a package B, apt at least offer the option of installing A
to replace B (i.e. remove B and install A). Currently, it doesn't.
> 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.)
If you refuse to read the document, how can you judge what it says?
I think I have narrowed down the crux of the problem to this simple
question that a dpkg expert like yourself ought to be able to explain
to me:
What is the difference between Conflicts: and Replaces:?
I thought, perhaps naively, that Conflicts was to indicate a conflict
(i.e. packages cannot be installed together) and that Replaces meant
that a package replaced another (i.e. that the upgrade path was to
remove the old package and to install the new one).
If that is not the case, then either these words are misleading, i don't
understand them or both.
--
Ludovic Brenta.
Reply to: