On 2014-11-10 14:22, Gianfranco Costamagna wrote: > There are two packages (not coinstallable) that both depends on the common > one. > > So you can have ettercap-graphical with ettercap-common > and you can have ettercap-text-only with ettercap-common. > > They both provide "ettercap", and they both depend on the common package.
> packages were also renamed, and some packages disappeared in the meanwhile > (ettercap-plugins, ettercap-gtk) > > this new package split is from 0.7.3, how do you suggest to fix? So you can simplify the package relationships using the virtual ettercap package (these must be unversioned relationships) Provides: ettercap Conflicts: ettercap Replaces: ettercap in both ettercap-graphical and ettercap-text-only. That means only one package providing (or being called) ettercap can be installed at a time. No need to have additionally Conflicts+Replaces: ettercap-other-current-implementation but keep the Conflicts+Replaces: ettercap-gtk to ensure the "ancient stuff" goes away. (Do you need that for ettercap-plugins, too?) ettercap-graphical will also need versioned Breaks+Replaces: ettercap-common (<< 1:0.8.1-2~) for finally taking over the .png file as only owner. If you get these changes into jessie, you clean clean this up for jessie+1 (or jessie+2) and only keep the Provides/Conflicts/Replaces: ettercap since the conflicting stuff is no longer in (old-)stable. > I'm proposing this debdiff, I didn't notice any upgrade path issues, and I > moved the files in the graphic package besides debian/control (discussed above) this looks good BTW, why are ettercap-graphical and ettercap-textonly not co-installable? Sounds like a candidate for renaming the binaries from ettercap to ettercap-foo and using alternatives to provide the ettercap binary. But that should not be considered now, only after the jessie release for jessie+1. Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
