2010/5/31 Ludovic Brenta <ludo...@ludovic-brenta.org>:
> David Kalnischkies wrote:
>> 2010/5/30 Ludovic Brenta <ludo...@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.
The only thing i can see from this "hint" is that dependencies are
missing. Fine, i guess i have talked about nothing else so far.
Whatever causes the removal of gnat-4.3 can e.g. also "Breaks"
all the packages who missed proper dependencies before.
>>> 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})
If A gets a binNMU 2+b1 this depends will be broken, as A-doc
will not be rebuilt in a binNMU - that was all i meant.
(Assuming that A-doc is a arch:all package and A arch:any)
> 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.
I talked about "Replaces", not about "Conflict". The Replaces is enough
to suggest an upgrade of the replaced package if possible, but okay,
lets drop it as it is relatively unrelated.
>> 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?
If it requires changes to all package managers to handle upgrades
in a nice way for this subcategory of packages as it was suggested here
i guess i can say that. I btw didn't say that i mean your/ada policy -
i said "a policy", so if ada policy doesn't change the sense of
dependencies (white to black) i can apply common rules (black)
and everything is fine. It just seems that i can't.
> 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:
dpkg is not my cup of tee, APT is. Anyway:
> What is the difference between Conflicts: and Replaces:?
All dependencies relations are defined in the policy [0],
for Replaces see e.g. [1].
In short: A Replaces only indicates that a file in package B
will be overridden - nothing more (and nothing less).
Just because a package overtakes a >file< doesn't automatically
mean i should install it. (see apt vs manpages-pl).
It absolutely doesn't have the sense of indicating package B
replaces package A completely. This is identical to a package
rename and can be handled as such.
Best regards,
David Kalnischkies
[0] http://www.debian.org/doc/debian-policy/ch-relationships.html
[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktikuolaxcm2kkxhjuhduqjjjoczfjbnystycb...@mail.gmail.com
