Bug#328310: gedit-common: problems with alternatives
tags 328310 + pending thanks Hi, On Thu, Sep 15, 2005, Josselin Mouette wrote: > > On my side, I'm looking at being policy compliant again, but it's not > > going to be funny (especially because of downgrades :-/). > > You only have to make the new gedit package conflict with the current > gedit-common. As alternatives are removed in the prerm, this is OK. Thanks for the hint. Bye, -- Loïc Minier <[EMAIL PROTECTED]>
Bug#328310: gedit-common: problems with alternatives
Le jeudi 15 septembre 2005 à 10:09 +0200, Loïc Minier a écrit : > - is it ok not to comply with policy when this never happens in >concrete usecases? (here, the use is never going to install >gedit-common without gedit) I believe this isn't OK. > On my side, I'm looking at being policy compliant again, but it's not > going to be funny (especially because of downgrades :-/). You only have to make the new gedit package conflict with the current gedit-common. As alternatives are removed in the prerm, this is OK. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Bug#328310: gedit-common: problems with alternatives
to, 2005-09-15 kello 10:09 +0200, Loïc Minier kirjoitti: > The interesting questions that come out of this is: > - would piuparts have detected this error if gedit-common recommended >gedit? I think so. Piuparts instructs apt-get to install the package and dependencies, and apt-get doesn't drag in recommended packages.
Bug#328310: gedit-common: problems with alternatives
Hi, On Wed, Sep 14, 2005, Lars Wirzenius wrote: > The postinst sets up a gnome-text-editor alternative, pointing it > to /usr/bin/gedit. Unfortunately, that file is not part of the > gedit-common package, so if the package is installed without gedit, > removal of the alternative fails, leaving cruft on the system. I guess > it would be better to move the alternatives handling into the gedit > package? > (I realize that this is a fairly unlikely scenario, but that's what > piuparts testing results in.) Thanks, this has started an interesting investigation on package dependencies because you filed two (very different) piuparts bugs against galeon/galeon-common and gedit/gedit-common the same day. The story is that gedit depends on gedit-common, and -- in the past -- gedit-common used to depend on gedit. The same is true of galeon/galeon-common. The dependencies were in a case removed (gedit-common does not depend on gedit) and in another one lowered (galeon-common recommends galeon) because of the circular deps issues during upgrades. The interesting questions that come out of this is: - would piuparts have detected this error if gedit-common recommended gedit? - is it ok not to comply with policy when this never happens in concrete usecases? (here, the use is never going to install gedit-common without gedit) On my side, I'm looking at being policy compliant again, but it's not going to be funny (especially because of downgrades :-/). Bye, -- Loïc Minier <[EMAIL PROTECTED]>
Bug#328310: gedit-common: problems with alternatives
Package: gedit-common Version: 2.10.3-4 The postinst sets up a gnome-text-editor alternative, pointing it to /usr/bin/gedit. Unfortunately, that file is not part of the gedit-common package, so if the package is installed without gedit, removal of the alternative fails, leaving cruft on the system. I guess it would be better to move the alternatives handling into the gedit package? (I realize that this is a fairly unlikely scenario, but that's what piuparts testing results in.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
