Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
(better late than never) 2010/6/1 Jacob Sparre Andersen ja...@jacob-sparre.dk: David Kalnischkies wrote: 2010/5/31 Ludovic Brenta ludo...@ludovic-brenta.org: Question 2: if I add Breaks: to a -dev package, which ones of Conflicts: and Replaces: should I also specify? (currently, both are specified; the new packages replace almost all files of the old packages). You want only Breaks or Conflicts. Breaks is in general the nicer Conflict - in some way they are the negative version of Depends and Pre-Depends: Conflicts must be satisfied before the package is unpacked - so both packages can't be in unpack (or higher) at the same time, while Breaks only says that both can't be in installed at the same time. So if there are common files, conflicts is required? You can still add Replaces to replace these files. Conflicts is now that we have Breaks more for cases in which the presence of a package will change the behavior of your package or in situations two packages providing the same functionality in completely different incompatible ways (e.g. sysvinit vs. upstart). Best regards, David Kalnischkies -- 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/aanlktilmfi7stxn-ua1rlt7njnr06iwlf9s4ompgk...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
(better late than never) 2010/6/3 Ludovic Brenta ludo...@ludovic-brenta.org: Jacob Sparre Andersen writes: David Kalnischkies wrote: With the break you can force the update of old-libs, which could depend in their new version on the new-libs. OK, I just tried that (in a local repository). Having gnat break all the -dev packages in Lenny does not help; the broken packages are marked as such in aptitude but not removed by default. Worse, gnat is now marked as broken too (without the Breaks: it is not). Even if I press '+' on gnat, this still does not cause any broken packages to be removed; I must mark them all for removal manually with '-'. So we're back to square one. Mhhh. What does broken mean here? As far as i know aptitude it should come up with a solution in the end in which all packages are in a consistent state (=not half-installed / unconfigured). So it should remove broken packages as broken is not a valid state a package can be after a complete $packagemanager run… Just for reference, what does apt-get dist-upgrade -s proposes? ( -o Debug::pkgProblemResolver=1 will tell you also why in a more or less cryptical way). It should really work to break old-lib ( squeeze version) in gnat, to force an upgrade of old-lib to (at least) the squeeze version, which could depend on your new-lib to get it installed… 2. the old-libs will stay installed in at least of the form of a transitional package in oldlibs as at least apt/lenny has no support for disappear packages so this trick can't be used (not sure about dpkg, aptitude uses apt facility in this regard, so also no support). This is ugly, but not horrible. Does apt/squeeze have support for disappearing packages? Yeap, or at least = 0.7.26~exp5 has and apt is registered for an abi transition/binnmu series so it will hopefully find its way into unstable/testing some day in the future… (currently blocked) Best regards, David Kalnischkies -- 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/aanlktim4_sfm0crslumw48coy--z2ifhhlypxn8en...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/6/6 Ludovic Brenta ludo...@ludovic-brenta.org: Package: gnat Architecture: any Depends: gnat-4.4 (= 4.4.2-1) Recommends: ada-reference-manual, gnat-gps Breaks: libadasockets-dev (= 1.8.6-2), libasis-dev, libaunit-dev, libaws-dev, libflorist-dev, libgnademysql-dev, libgnadeodbc-dev, libgnadepostgresql-dev, libgnadesqlite-dev, libgnatprj4.3-dev, libgnatvsn4.3-dev, libgnomeada2-dev, libgtkada2-dev, libtemplates-parser-dev, libtexttools-dev, libxmlada-dev These breaks need to be versioned - e.g. libasis-dev ( squeeze) there squeeze is the version of the transitional package libasis-dev which depends on the new libasis-newabi-dev just like in a package rename. 2. the old-libs will stay installed in at least of the form of a transitional package in oldlibs as at least apt/lenny has no support for disappear packages so this trick can't be used (not sure about dpkg, aptitude uses apt facility in this regard, so also no support). This is ugly, but not horrible. Does apt/squeeze have support for disappearing packages? Yeap, or at least = 0.7.26~exp5 has and apt is registered for an abi transition/binnmu series so it will hopefully find its way into unstable/testing some day in the future… (currently blocked) Could you shed some light or point me to some doc as to how this feature works? I'd like to know whether it can solve the problem or not. E.g here http://wiki.debian.org/Renaming_a_Package It is not documented very well currently as it can't be used for squeeze and would therefore most likely only confuse maintainers (i guess). Disappear should remove the need in the future for transitional packages (see apt-cache search dummy transitional). Best regards, David Kalnischkies -- 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/aanlktimhxgmdss7xhlsjwnzijy1wjtwlwpf0txqwf...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies writes: 2010/6/6 Ludovic Brenta ludo...@ludovic-brenta.org: Package: gnat Architecture: any Depends: gnat-4.4 (= 4.4.2-1) Recommends: ada-reference-manual, gnat-gps Breaks: libadasockets-dev (= 1.8.6-2), libasis-dev, libaunit-dev, libaws-dev, libflorist-dev, libgnademysql-dev, libgnadeodbc-dev, libgnadepostgresql-dev, libgnadesqlite-dev, libgnatprj4.3-dev, libgnatvsn4.3-dev, libgnomeada2-dev, libgtkada2-dev, libtemplates-parser-dev, libtexttools-dev, libxmlada-dev These breaks need to be versioned - e.g. libasis-dev ( squeeze) there squeeze is the version of the transitional package libasis-dev which depends on the new libasis-newabi-dev just like in a package rename. As discussed before, introducing transitional packages would be sufficient to guarantee smooth upgrades (without the need for Breaks in gnat) but it would also defeat the purpose of the aliversion component of packages names. We do not want any transitional packages. Consequently, the version numbers are also unnecessary (except in the case of libadasockets-dev due to #580907). I believe this is as far as we can go; apt simply does not offer the feature that we would need, i.e. a way to explain that apt should remove a package libX1-dev (which disappeared from the archive) and install libX2-dev (new in the archive) as the upgrade path. 2. the old-libs will stay installed in at least of the form of a transitional package in oldlibs as at least apt/lenny has no support for disappear packages so this trick can't be used (not sure about dpkg, aptitude uses apt facility in this regard, so also no support). This is ugly, but not horrible. Does apt/squeeze have support for disappearing packages? Yeap, or at least = 0.7.26~exp5 has and apt is registered for an abi transition/binnmu series so it will hopefully find its way into unstable/testing some day in the future… (currently blocked) Could you shed some light or point me to some doc as to how this feature works? I'd like to know whether it can solve the problem or not. E.g here http://wiki.debian.org/Renaming_a_Package I've already read that and it has not changed since then (I checked the change history). Basically, both methods require a transitional package; we cannot use that for Ada -dev packages. It is not documented very well currently as it can't be used for squeeze and would therefore most likely only confuse maintainers (i guess). Disappear should remove the need in the future for transitional packages (see apt-cache search dummy transitional). OK. I think we'll let the issue rest and try do document why unattended in-place upgrades are not supported for Ada development packages. I already have a draft of this in the next edition of the Debian Policy for Ada. We will revisit this issue in squeeze+1. -- Ludovic Brenta. -- 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/87r5kjrict@ludovic-brenta.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Jacob Sparre Andersen writes: David Kalnischkies wrote: 2010/5/31 Ludovic Brenta ludo...@ludovic-brenta.org: Option 1: upload a new package gnat that Breaks: all -dev packages that were present in Lenny but are no longer present in Squeeze. This however does not really help apt, or the user, discover the new replacement packages. Option 2: change each new -dev package so that it Breaks: its predecessor. For example, let libgtkada2.14.2-dev Break: libgtkada2.8.1-dev. As far as i understand can the old lib-packages not be used with the new gnat. Right? Yes. If so i would say gnat should Break them. Breaking them in the new-libs will not help as the new-libs still need to be installed to get the Breaks effect - and they are broken before. OK. With the break you can force the update of old-libs, which could depend in their new version on the new-libs. OK, I just tried that (in a local repository). Having gnat break all the -dev packages in Lenny does not help; the broken packages are marked as such in aptitude but not removed by default. Worse, gnat is now marked as broken too (without the Breaks: it is not). Even if I press '+' on gnat, this still does not cause any broken packages to be removed; I must mark them all for removal manually with '-'. So we're back to square one. I don't see another route to install the new-libs, but 1. Is this really needed? If the user needs them they are an apt-get install (or similar) away. new-lib isn't a drop-in replacement for old-lib (or?) and (s)he therefore needs to learn a new way anway? At the very least, the user must recompile their applications. But you are correct that since the aliversion changed, chances are high that the user must also review the semantic changes between the old and the new libs. Luckily the compiler and the rules of the Ada language make it very easy to discover incompatibilities at compile time. In most cases new-lib is a perfect replacement for old-lib, so getting new-lib installed where old-lib was installed is definitely preferable to have to install it manually. I agree but having them uninstalled by default is less bad than having them broken by default. 2. the old-libs will stay installed in at least of the form of a transitional package in oldlibs as at least apt/lenny has no support for disappear packages so this trick can't be used (not sure about dpkg, aptitude uses apt facility in this regard, so also no support). This is ugly, but not horrible. Does apt/squeeze have support for disappearing packages? Thanks for your help so far; any other ideas anyone? Currently I've resorted to writing a (yes unpublished) user's guide in the Debian Policy for Ada that instructs how to mark all old Ada -dev packages for removal and to mark all new ones for installation. Manually :( -- Ludovic Brenta. -- 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/87ocfr26ut@ludovic-brenta.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/31 Ludovic Brenta ludo...@ludovic-brenta.org: Option 1: upload a new package gnat that Breaks: all -dev packages that were present in Lenny but are no longer present in Squeeze. This however does not really help apt, or the user, discover the new replacement packages. Option 2: change each new -dev package so that it Breaks: its predecessor. For example, let libgtkada2.14.2-dev Break: libgtkada2.8.1-dev. As far as i understand can the old lib-packages not be used with the new gnat. Right? If so i would say gnat should Break them. Breaking them in the new-libs will not help as the new-libs still need to be installed to get the Breaks effect - and they are broken before. With the break you can force the update of old-libs, which could depend in their new version on the new-libs. I don't see another route to install the new-libs, but 1. Is this really needed? If the user needs them they are an apt-get install (or similar) away. new-lib isn't a drop-in replacement for old-lib (or?) and (s)he therefore needs to learn a new way anway… 2. the old-libs will stay installed in at least of the form of a transitional package in oldlibs as at least apt/lenny has no support for disappear packages so this trick can't be used (not sure about dpkg, aptitude uses apt facility in this regard, so also no support). The other option is to follow one and only Breaks the old-libs away. This way you get right of the old-libs packages with the expense that new-libs are not installed automatically. Question 2: if I add Breaks: to a -dev package, which ones of Conflicts: and Replaces: should I also specify? (currently, both are specified; the new packages replace almost all files of the old packages). You want only Breaks or Conflicts. Breaks is in general the nicer Conflict - in some way they are the negative version of Depends and Pre-Depends: Conflicts must be satisfied before the package is unpacked - so both packages can't be in unpack (or higher) at the same time, while Breaks only says that both can't be in installed at the same time. Best regards, David Kalnischkies -- 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/aanlktikdsnc7bdzyeyf4uqkc9czacnfkvpfsak3bo...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies wrote: 2010/5/31 Ludovic Brenta ludo...@ludovic-brenta.org: Option 1: upload a new package gnat that Breaks: all -dev packages that were present in Lenny but are no longer present in Squeeze. This however does not really help apt, or the user, discover the new replacement packages. Option 2: change each new -dev package so that it Breaks: its predecessor. For example, let libgtkada2.14.2-dev Break: libgtkada2.8.1-dev. As far as i understand can the old lib-packages not be used with the new gnat. Right? Yes. If so i would say gnat should Break them. Breaking them in the new-libs will not help as the new-libs still need to be installed to get the Breaks effect - and they are broken before. OK. With the break you can force the update of old-libs, which could depend in their new version on the new-libs. I don't see another route to install the new-libs, but 1. Is this really needed? If the user needs them they are an apt-get install (or similar) away. new-lib isn't a drop-in replacement for old-lib (or?) and (s)he therefore needs to learn a new way anway? In most cases new-lib is a perfect replacement for old-lib, so getting new-lib installed where old-lib was installed is definitely preferable to have to install it manually. 2. the old-libs will stay installed in at least of the form of a transitional package in oldlibs as at least apt/lenny has no support for disappear packages so this trick can't be used (not sure about dpkg, aptitude uses apt facility in this regard, so also no support). This is ugly, but not horrible. Question 2: if I add Breaks: to a -dev package, which ones of Conflicts: and Replaces: should I also specify? (currently, both are specified; the new packages replace almost all files of the old packages). You want only Breaks or Conflicts. Breaks is in general the nicer Conflict - in some way they are the negative version of Depends and Pre-Depends: Conflicts must be satisfied before the package is unpacked - so both packages can't be in unpack (or higher) at the same time, while Breaks only says that both can't be in installed at the same time. So if there are common files, conflicts is required? Greetings, Jacob -- I have no prejudice except against Pakistanis, which is normal.
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/30 Ludovic Brenta ludo...@ludovic-brenta.org: David Kalnischkies kalnischkies+deb...@gmail.com writes: 2010/5/29 Ludovic Brenta ludo...@ludovic-brenta.org: David Kalnischkies kalnischkies+deb...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
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.
[...]
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.
--
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/bf5e9602880444a6f3511ef863627...@localhost
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
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
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies wrote: 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. (side note: I've been a Debian developer since before Breaks: even existed, so I was unaware of its presence until this thread. This may be what I was looking for all along.) OK. After reading Policy about Breaks, I'm still not entirely sure how to best apply it. Maybe you can enlighten me. I am thinking of two options; maybe there is a third one that eludes me ATM. Option 1: upload a new package gnat that Breaks: all -dev packages that were present in Lenny but are no longer present in Squeeze. This however does not really help apt, or the user, discover the new replacement packages. Option 2: change each new -dev package so that it Breaks: its predecessor. For example, let libgtkada2.14.2-dev Break: libgtkada2.8.1-dev. Question 1: which option do you think is best? (my guess is option 2). Question 2: if I add Breaks: to a -dev package, which ones of Conflicts: and Replaces: should I also specify? (currently, both are specified; the new packages replace almost all files of the old packages). The goal is, of course, to make unattended upgrades that delete the old -dev packages and install the new ones possible. Thanks for any help. -- Ludovic Brenta. -- 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/e10a64e9ed6898b22e8643d48aa49...@localhost
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/29 Ludovic Brenta ludo...@ludovic-brenta.org: David Kalnischkies kalnischkies+deb...@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 -- 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/aanlktimyqurbfoka7n_dye0tfiytnmjrkpue9fxi1...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies kalnischkies+deb...@gmail.com writes: 2010/5/29 Ludovic Brenta ludo...@ludovic-brenta.org: David Kalnischkies kalnischkies+deb...@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. Suppose package A (=1) contains /usr/share/doc/A/examples/config; the successor is A-doc (=2) which contains /usr/share/doc/A-doc/examples/config. There is no file conflict and no need for Conflicts: or Replaces:. Now, just to make the example more twisted, suppose the new A-doc contains a symlink: /usr/share/doc/A-doc - A and, of course, Depends: on the exact version of A, i.e. Package: A-doc Depends: A (=2) (per Debian Policy in such cases). Then there is still no conflict and no need for Conflicts: or Replaces: because A-doc can never be installed at the same time as the old A. Should a package manager really follow the Replaces? I think so, yes. If I take the trouble to specify Replaces, I mean it. If I do *not* want the package manager to follow the Replaces, then I specify Conflicts but *not* Replaces. Why else do we have two different relationships? This would mean we could end up removing A because A-doc replaces it? No, per my explanation above; instead, the package manager would install the new A and the new A-doc. 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? I do not think mail-transport-agents should necessarily Replace each other. They should only Conflict with each other. 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… The problem with -dev packages is that, usually, nothing depends on them (apart for other -dev packages); they are only ever installed when a user explicitly requests so, so aptitude will *not* autoremove them. 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. 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… 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. -- Ludovic Brenta. -- 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/87wrul5d24@ludovic-brenta.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies kalnischkies+deb...@gmail.com writes: 2010/5/28 Stephen Leake stephen_le...@stephe-leake.org: Ludovic Brenta ludo...@ludovic-brenta.org writes: Stephen Leake wrote: Ludovic Brenta ludo...@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. 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 … Yes, that is all true. It is also required by the rules of the Ada language. Please read the Debian Ada policy [1] (in particular, section 3.2) for an explanation of this naming convention. This is normally done for Package renames and described in e.g. http://wiki.debian.org/Renaming_a_Package That is an excellent suggestion; I'll try it. So i would recommend to describe more what you actually want and your specific problem That was done by Ludovic's original post in this thread. [1] http://people.debian.org/~lbrenta/debian-ada-policy.html -- -- Stephe -- 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/827hmmsrp6@stephe-leake.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies kalnischkies+deb...@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? I do agree with the rest of what you said. 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. -- Ludovic Brenta. -- 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/87ljb279yb@ludovic-brenta.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Ludovic Brenta ludo...@ludovic-brenta.org writes: Stephen Leake wrote: Ludovic Brenta ludo...@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. Debian policy 7.6.2 says that Replaces: with Conflicts: should cause the old package to be removed, and the new package to be installed, so why doesn't this work? That's because there is no conflict until the user asks for installation of the new package; 7.6.2 says the old package must go only in case of a conflict. So, I would not characterize the behavior of aptitude as a bug, merely an annoyance. Ok. 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. Currently, a package is upgraded only if its name does not change. Package names can change, either because of aliversions, or for other reasons. So an Upgrades control field to identify package name changes would be appropriate. Or maybe it should be a Renames control field. That could also allow uploading without going thru the new packages process. 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. Another option would be to teach dpkg to treat the aliversion in the same way it currently treats other version numbers; that is, not as part of the name, so it would know that libopentoken2-dev is the proper upgrade from libopentoken1-dev. We might have to add some separator syntax for the aliversion for that to work. -- -- Stephe -- 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/826328tf4y@stephe-leake.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Stephen Leake wrote: Currently, a package is upgraded only if its name does not change. Good point. Is the hack then to introduce a new libnameold-ali-dev package which is empty but depends on libnamenew-ali-dev? Lots of empty packages, just to get the upgrade to work, but if we have a plan for avoiding this in the future, then I think it is an acceptable (but far from perfect) solution to the immediate problem. Greetings, Jacob -- Good enough for physics -- Ridcully -- 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/alpine.deb.2.00.1005281432250.3...@hugsarin.sparre-andersen.dk
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/28 Stephen Leake stephen_le...@stephe-leake.org: Ludovic Brenta ludo...@ludovic-brenta.org writes: Stephen Leake wrote: Ludovic Brenta ludo...@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_le...@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) -- 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/aanlktik96wdwal1imqqkm_fzkqyfb0vnsdnb6ywmp...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Ludovic Brenta ludo...@ludovic-brenta.org writes: Over the last two weeks I have been testing upgrades of Ada packages from Lenny to Sid and Squeeze in a chroot. Thanks for looking at this. ... 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. Debian policy 7.6.2 says that Replaces: with Conflicts: should cause the old package to be removed, and the new package to be installed, so why doesn't this work? -- -- Stephe -- 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/82ljb5u0au@stephe-leake.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Stephen Leake wrote: Ludovic Brenta ludo...@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. Debian policy 7.6.2 says that Replaces: with Conflicts: should cause the old package to be removed, and the new package to be installed, so why doesn't this work? That's because there is no conflict until the user asks for installation of the new package; 7.6.2 says the old package must go only in case of a conflict. So, I would not characterize the behavior of aptitude as a bug, merely an annoyance. -- Ludovic Brenta. -- 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/f1b376860d7dbf4f911f1fc54baeb...@localhost
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Ludovic Brenta wrote:
Over the last two weeks I have been testing upgrades of
Ada packages from Lenny to Sid and Squeeze in a chroot.
The picture is not as pretty as it should be. In a
nutshell, when you change /etc/apt/sources.list from lenny
to squeeze (unstable, actually) and do aptitude update,
you end up with a lot of broken packages and must
intervene manually to resolve the problem (i.e. remove the
broken packages, install new versions).
A long-term, partial solution is to introduce a
build-essential-ada package, which depends on gnat and all
the current development packages. That would also make it
quicker to prepare a new system for developing Ada programs.
(As a teacher, it is a package I have missed a lot.)
In the case of libgnat{vsn,prj}4.3-dev, this is only
because I recently added dummy transition packages,
libgnat{vsn,prj}-dev in gnat-4.4 (= 4.4.4-4).
Could you create such dummy transition packages for all
development packages? (Again only a long-term solution.)
I think a short-term solution might be to make gnat suggest
the new versions of the development packages. (Or the
above-mentioned transition packages?)
Greetings,
Jacob
--
There are only two types of data:
Data which has been backed up
Data which has not been lost - yet
--
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/alpine.deb.1.10.1005260705510.8...@munin.nbi.dk
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Jacob Sparre Andersen wrote:
Ludovic Brenta wrote:
Over the last two weeks I have been testing upgrades of
Ada packages from Lenny to Sid and Squeeze in a chroot.
The picture is not as pretty as it should be. In a
nutshell, when you change /etc/apt/sources.list from lenny
to squeeze (unstable, actually) and do aptitude update,
you end up with a lot of broken packages and must
intervene manually to resolve the problem (i.e. remove the
broken packages, install new versions).
A long-term, partial solution is to introduce a
build-essential-ada package, which depends on gnat and all
the current development packages. That would also make it
quicker to prepare a new system for developing Ada programs.
(As a teacher, it is a package I have missed a lot.)
OK, since there is user demand, it seems reasonable. Note that
the build-essential-ada package really is the gnat package;
a new package that brings in the whole shebang would rather be
called complete-ada-development-environment-with-bells-and-
whistles :)
In the case of libgnat{vsn,prj}4.3-dev, this is only
because I recently added dummy transition packages,
libgnat{vsn,prj}-dev in gnat-4.4 (= 4.4.4-4).
Could you create such dummy transition packages for all
development packages? (Again only a long-term solution.)
No; the whole point of the package name changes is to break
the Depends: of third-party programs before they FTBFS for
reasons mysterious to the programmer but obvious to the
Debian Ada maintainers :)
I think a short-term solution might be to make gnat suggest
the new versions of the development packages. (Or the
above-mentioned transition packages?)
That seems quite reasonable but a Recommends: would be needed
to force automatic package upgrades (i.e. deletion of the old
packages and installation of new ones). The other drawback is
that it would be necessary to change the gnat package each
time a new -dev package appears in Debian :) I think we can
live with such a drawback for the time being.
Thanks for the feedback.
--
Ludovic Brenta.
--
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/af6b1e49e807b6fdf4d1fadd814dd...@localhost
