On 2017-02-12 07:01, Roopa Prabhu wrote: > Andreas, Thanks for reporting the issue. We can add 'Conflicts: ifupdown'. > Infact earlier versions of ifupdown2 > did have the "Conflicts: ifupdown"...but in order to have both > ifupdown and ifupdown2 co-exist, we removed the "Conflicts: ifupdown" in the > recent versions of ifupdown2. > We did this primarily to not confuse existing applications that already > depend on ifupdown...keeping them > both available seemed to be a better option. > > Coming back to the problem you hit: > - ifupdown2 does not divert /etc/default/networking (Julien can re-confirm). and you cannot divert conffiles, so this is a show-stopper for co-installation of ifupdown and ifupdown2 (unless ifupdown can Depends: ifupdown and use /etc/default/networking from ifupdown)
To have them co-installable you need to be able to remove the (unversioned) Replaces: ifupdown (a versioned Breaks+Replaces against some older version would be ok) > - One thing that i do see not happening cleanly after the purge of ifupdown2 > is passing ownership of > /lib/systemd/system/networking.service to ifupdown (same thing you are > pointing out) > Which makes me think that, /lib/system/system/networking.service should also > be diverted by ifupdown2. > > so, one fix in ifupdown2 would be: > preinstall > - divert /lib/system/system/networking.service > > postrm > - restore diverted /lib/system/system/networking.service > > Will you be ok with such a fix ?. that would be ok care must be taken with the systemd integration, i.e. networking.service must not be disabled after removing ifupdown2 if ifupdown is installed For stretch I'd suggest to reinstate the Conflicts and then look for a better solution for clean co-installability targetting buster. Andreas
