Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/28 Stephen Leake <stephen_leake@stephe-leake.org>:
> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>
>> Stephen Leake wrote:
>>> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>>>> The reason for all this is that when a package libX2-dev Conflicts:
>> with
>>>> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
>>>> and install libX2-dev; instead, it marks libX1-dev as broken and leaves
>>>> libX2-dev uninstalled.
>>>
>>> This seems like a clear bug in aptitude.
This seems like a bug in your understanding, not in apt(itude).
The name libX1-dev suggests that it can be co-installed with libX2-dev and co
as otherwise the version number wouldn't make much sense
(yeah i know, in a few other cases… i said not much) - automatic
updates in which libX1-dev is killed for good by libX2-dev is absolutely
not what i would expect as packages will (build-)depend on libX1-dev which
obviously can not be satisfied by libX2-dev -- if it could it would be called
libX1-dev also or even libX-dev and only the real library is called libX2 …
2010/5/28 Stephen Leake <stephen_leake@stephe-leake.org>:
> But it seems the best way to reduce the annoyance is to improve aptitude
> (or dpkg). Add an option that says "treat Replaces as the correct
> upgrade path". Or add a new control field Upgrades for that purpose.
Replaces form the correct upgrade path?
I really thing Depends form the upgrade path - and all the negative ones
just make it more complicated. ;) (or more serious: give additional hints)
Negative Dependencies have a serious problem: A package manager
can choose to retreat from upgrading a package because it would
e.g. break to much - and that is in your interest!
But do not only shoot into the dark, each manager has debugoptions
to show you why it does certain things. Looking at these decisions
can help a lot in understand how to express dependencies ((pre)depends,
recommends, suggests, replaces, conflicts, provides, breaks, …)
correctly (or it will lead you into insanity, depending on how pain
resistant you are ;) ).
> However, my reading of Debian policy gave me the impression that
> Replaces was supposed to be used for that purpose. Since the tools
> currently do not fully support that use, I think they are broken.
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. It also does not say that B will replaces A completely -
this is maybe the case, maybe not (it replaces only a single file).
Provides give the indication that B is a complete replacement for A,
but in this case you should be sure that it is really a complete replacement.
libX2-dev can't provide libX1-dev for example - or it could but only if
all packages which work with libX1-dev can be built without a change
with libX2-dev instead of libX1-dev.
This also eliminates the idea to let libX1-dev be a dummy package
only depending on libX2-dev as the packages building against libX1-dev
will be (completely) broken.
This is normally done for Package renames and described in e.g.
http://wiki.debian.org/Renaming_a_Package
Method B will in future (squeeze+1) take care of these dummy empty
packages if the maintainer does it correct. Until then we need to handle
them with autoremove and co - which is yet another "interesting" and
complicated problem…
So i would recommend to describe more what you actually want and
your specific problem so people can help you
(maybe the questions are a better fit in d-mentors) and not what you think
is a bug in a package manager - if it is really a bug it should be expressed
with a proper bugreport against the package manager in question…
Best regards,
David Kalnischkies (Debian APT GSoC student)
Reply to: