Re: What is the use case for Policy §7.6.2 ?
On Fri, 09 Nov 2012, Josselin Mouette wrote: It looks to me that we should strictly favor the transitional package approach instead. Shouldn’t we entirely forbid the Provides/Conflicts/Replaces combination way of handling upgrades, except for virtual packages? And instantly break even further the upgrade path of lots of already-published packages? This is the sort of thing that might need a deployment plan over two stable releases, it is probably better to find a way to fix apt. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20121109124628.ga8...@khazad-dum.debian.net
Re: What is the use case for Policy §7.6.2 ?
Hi Josselin! On Fri, 09 Nov 2012, Henrique de Moraes Holschuh wrote: On Fri, 09 Nov 2012, Josselin Mouette wrote: It looks to me that we should strictly favor the transitional package approach instead. Shouldn’t we entirely forbid the Provides/Conflicts/Replaces combination way of handling upgrades, except for virtual packages? And instantly break even further the upgrade path of lots of already-published packages? This is the sort of thing that might need a deployment plan over two stable releases, it is probably better to find a way to fix apt. Meh, never mind, it was a major thinko on my part, and I apologise. We could certainly keep the current support in the tools, but forbid the usage of the fields in that way for the future. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20121109125322.gb8...@khazad-dum.debian.net
Re: What is the use case for Policy §7.6.2 ?
Josselin Mouette j...@debian.org writes: the Debian policy makes a special case of the Provides/Conflicts/Replaces combination, allowing to replace a package by another. The document mentions the case of a virtual package, for which this is nice and all, but it is still allowed for other packages. However, any versioned dependency is broken when you handle upgrades this way. Even worse, APT does not handle such situations very well. Bug #691160 is a good example of what happens in a bad case (the old package not being installable anymore). Arguably this is a bug in APT, but we are more prone to such bugs by allowing arcane relationships between packages. It looks to me that we should strictly favor the transitional package approach instead. Shouldn’t we entirely forbid the Provides/Conflicts/Replaces combination way of handling upgrades, except for virtual packages? That makes sense to me on first glance. I can't think of a case where I'd want to use Provides/Conflicts/Replaces with non-virtual packages rather than using a transitional package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87obj63axy@windlord.stanford.edu
Re: What is the use case for Policy §7.6.2 ?
On Fri, 09 Nov 2012, Russ Allbery wrote: That makes sense to me on first glance. I can't think of a case where I'd want to use Provides/Conflicts/Replaces with non-virtual packages rather than using a transitional package. I'm currently using this in the case of unscd and nscd. It's useful to be able to do this when there are not any versioned dependencies on the provided package, and one needs to take over the configuration files of the package that is being conflicted with. Just forbidding P/C/R in when there are (potentially) versioned dependencies should be enough, I think. Don Armstrong -- life's not a paragraph And death i think is no parenthesis -- e.e. cummings Four VII _is 5_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20121109183941.gh11...@rzlab.ucr.edu
