Bug#328310: gedit-common: problems with alternatives

[Loïc Minier]

        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 <lool at dooz.org>