Bug#768831: ettercap-common, ettercap-graphical: shipping the same file: usr/share/ettercap/ettercap.png
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
Bug#768831: ettercap-common, ettercap-graphical: shipping the same file: usr/share/ettercap/ettercap.png
Thanks, that sounds like exactly the right debian/control dependency magic. Will do, and upload. 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. Reasonable question. The reason is that the graphical binary provides the functionality of the textual binary *plus* a GUI-enabled option. There are no circumstances in which installing both at the same time makes sense. The main reason for generating the non-graphical is for boxes without X etc installed, which is actually a pretty common use case for ettercap. That said, I wouldn't particularly object to using alternatives to allow co-installation just in case. Although I'd be inclined to provide the functionality by instead using dpkg-divert in ettercap-graphical to move the text-only version of /usr/bin/ettercap to /usr/bin/ettercap-text-only, thus avoiding unnecessarily increasing the footprint of ettercap-text-only. --Barak. signature.asc Description: PGP signature
Bug#768831: ettercap-common, ettercap-graphical: shipping the same file: usr/share/ettercap/ettercap.png
On 2014-11-11 13:25, Barak A. Pearlmutter wrote: That said, I wouldn't particularly object to using alternatives to allow co-installation just in case. Although I'd be inclined to provide the functionality by instead using dpkg-divert in ettercap-graphical to move the text-only version of /usr/bin/ettercap to /usr/bin/ettercap-text-only, thus avoiding unnecessarily increasing the footprint of ettercap-text-only. That's a solution as well, but it won't easily scale beyond 2 packages. (I have enough experience diverting libGL.so* and friends from MESA and implementing a alternatives-based switching method for the proprietary drivers.) Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768831: ettercap-common, ettercap-graphical: shipping the same file: usr/share/ettercap/ettercap.png
That's a solution as well, but it won't easily scale beyond 2 packages. THERE CAN BE ONLY TWO! Really only one makes sense, even two is stretching it. I suppose theoretically we could have ettercap-text-no-ncurses ettercap-ncurses ettercap-graphical and maybe even ettercap-daemon-only but I still don't see any use case for having more than one installed. The reason for only having two (of which only one should actually be intalled) was that it was thought that any platform powerful enough to run ettercap would have libncurses, so a no-ncurses version doesn't make sense, even though that is a supported configuration. A daemon-only configuration might make sense for very small systems like embedded routers, but that is not a supported configuration and would therefore require a bit of hacking. Not a bad idea, hmmm? --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ signature.asc Description: PGP signature
Bug#768831: ettercap-common, ettercap-graphical: shipping the same file: usr/share/ettercap/ettercap.png
Hi Andreas, The ettercap-graphical package has the following relationships with ettercap-common: Conflicts: N/A Breaks:N/A Replaces: ettercap, ettercap-common, ettercap-gtk, ettercap-text-only I don't see what you want to achieve with these Replaces, so I cannot suggest a better solution. Please read the policy (and explain your intentions if you need help). Have packages been split? (version?) Have files moved between the packages? (version?) Should packages not be installable at the same time? there is one common package with the library, the common files, and everything shared. 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? I'm proposing this debdiff, I didn't notice any upgrade path issues, and I moved the files in the graphic package diff -Nru ettercap-0.8.1/debian/changelog ettercap-0.8.1/debian/changelog --- ettercap-0.8.1/debian/changelog 2014-10-18 11:17:12.0 +0200 +++ ettercap-0.8.1/debian/changelog 2014-11-10 14:16:59.0 +0100 @@ -1,3 +1,14 @@ +ettercap (1:0.8.1-2) unstable; urgency=medium + + * Remove byacc | byacc-j | btyacc, not compatible after +the cmake switch. + * Add flex-old as b-d, used with bison++. + * Fix conflicting files in both common and graphical package +(Closes: #768831). + * Remove the gksu dependency, not needed anymore. + + -- Gianfranco Costamagna costamagnagianfra...@yahoo.it Tue, 21 Oct 2014 13:19:19 +0200 + ettercap (1:0.8.1-1) unstable; urgency=medium * New upstream release. diff -Nru ettercap-0.8.1/debian/control ettercap-0.8.1/debian/control --- ettercap-0.8.1/debian/control 2014-10-18 11:17:12.0 +0200 +++ ettercap-0.8.1/debian/control 2014-11-10 14:16:08.0 +0100 @@ -4,12 +4,12 @@ Maintainer: Barak A. Pearlmutter b...@debian.org Uploaders: Murat Demirten mu...@debian.org, Gianfranco Costamagna costamagnagianfra...@yahoo.it -Build-Depends: bison | bison++ | byacc | byacc-j | btyacc, +Build-Depends: bison | bison++, check, chrpath, cmake, debhelper (= 9), - flex, + flex | flex-old, ghostscript, libbsd-dev, libcurl4-openssl-dev, @@ -88,7 +88,6 @@ Replaces: ettercap, ettercap-common, ettercap-gtk, ettercap-text-only Conflicts: ettercap (= 1:0.7.3), ettercap-gtk, ettercap-text-only Provides: ettercap -Recommends: gksu Description: Ettercap GUI-enabled executable Ettercap supports active and passive dissection of many protocols (even encrypted ones) and includes many feature for network and host diff -Nru ettercap-0.8.1/debian/ettercap-common.install ettercap-0.8.1/debian/ettercap-common.install --- ettercap-0.8.1/debian/ettercap-common.install 2014-10-18 11:17:12.0 +0200 +++ ettercap-0.8.1/debian/ettercap-common.install 2014-11-10 12:45:08.0 +0100 @@ -2,9 +2,10 @@ /usr/bin/etterfilter /usr/bin/etterlog /usr/lib/ -/usr/share/ettercap -# The next line accidentally gets +# The next lines accidentally gets # /usr/share/man/ettercap-pkexec* +# and /usr/share/ettercap/ettercap.png # which belongs in ettercap-graphical. # This is worked around in debian/rules. +/usr/share/ettercap /usr/share/man diff -Nru ettercap-0.8.1/debian/ettercap-graphical.install ettercap-0.8.1/debian/ettercap-graphical.install --- ettercap-0.8.1/debian/ettercap-graphical.install2014-10-18 11:17:12.0 +0200 +++ ettercap-0.8.1/debian/ettercap-graphical.install2014-11-10 12:45:11.0 +0100 @@ -2,7 +2,8 @@ /usr/bin/ettercap-pkexec /usr/share/appdata /usr/share/applications -/usr/share/ettercap/ettercap.png +/usr/share/ettercap/*.png +/usr/share/ettercap/*.svg /usr/share/man/man*/ettercap-pkexec* /usr/share/pixmaps /usr/share/polkit-1 diff -Nru ettercap-0.8.1/debian/rules ettercap-0.8.1/debian/rules --- ettercap-0.8.1/debian/rules 2014-10-18 11:17:12.0 +0200 +++ ettercap-0.8.1/debian/rules 2014-11-10 12:45:11.0 +0100 @@ -56,6 +56,8 @@ dh_install --list-missing @echo The ettercap-pkexec man page belongs in ettercap-graphical -rm --verbose debian/ettercap-common/usr/share/man/man*/ettercap-pkexec* + -rm --verbose debian/ettercap-common/usr/share/ettercap/*.png + -rm --verbose debian/ettercap-common/usr/share/ettercap/*.svg @echo Upstream does not set RPATH, but the file is not handled by cmake install (dh_auto_install target) chrpath --list debian/ettercap-text-only/usr/bin/ettercap chrpath --delete debian/ettercap-text-only/usr/bin/ettercap is it ok for you? (sorry for the flex noise) thanks, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of
Bug#768831: ettercap-common, ettercap-graphical: shipping the same file: usr/share/ettercap/ettercap.png
Package: ettercap-common,ettercap-graphical Version: 1:0.8.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts replaces-without-breaks Hi, during a test with piuparts and DOSE tools I noticed your package causes removal of files that also belong to another package. This is caused by using Replaces without corresponding Breaks. And of course by shipping the same file in two packages: usr/share/ettercap/ettercap.png which looks like an incomplete move to another package. The installation sequence to reproduce this problem is apt-get install ettercap-common # (1) apt-get install ettercap-graphical apt-get remove ettercap-graphical # (2) The list of installed files at points (1) and (2) should be identical, but the following files have disappeared: usr/share/ettercap/ettercap.png This is a serious bug violating policy 7.6, see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces and also see the footnote that describes this incorrect behavior http://www.debian.org/doc/debian-policy/footnotes.html#f53 The ettercap-graphical package has the following relationships with ettercap-common: Conflicts: N/A Breaks:N/A Replaces: ettercap, ettercap-common, ettercap-gtk, ettercap-text-only I don't see what you want to achieve with these Replaces, so I cannot suggest a better solution. Please read the policy (and explain your intentions if you need help). Have packages been split? (version?) Have files moved between the packages? (version?) Should packages not be installable at the same time? From the attached log (scroll to the bottom...): 0m25.8s ERROR: FAIL: After purging files have disappeared: /usr/share/ettercap/ettercap.png owned by: ettercap-graphical 0m25.8s ERROR: FAIL: After purging files have been modified: /var/lib/dpkg/info/ettercap-common.listnot owned cheers, Andreas ettercap-common=1%0.8.1-1_ettercap-graphical=1%0.8.1-1.log.gz Description: application/gzip
