On 2017-02-12 19:46, Roopa Prabhu wrote: > On 2/12/17, 1:29 AM, Andreas Beckmann wrote: >> 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) > > good point. I think one solution here would be that ifupdown2 not use > /etc/default/networking and use > something like /etc/default/networking-ifupdown2 (pls let us know if that is > ok, or it violates a debian policy).
I don't see any problem here. If you do this, you need to file a bug against ifupdown to add Breaks+Replaces: ifupdown2 (<< $FIXEDIFUPDOWN2VERSION~) to ensure /etc/default/networking gets reclaimed by 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 > > yes, this is something we will need to check. >> >> For stretch I'd suggest to reinstate the Conflicts and then look for a >> better solution for clean co-installability targetting buster. >> > > that is a good suggestion. > The only thing is, we have gone back and forth on the Conflicts. And > wondering if fixing the dependencies > here would be better than than going back to Conflicts again. > > so we have two solutions: > (a) fix /etc/default/networking conflict situation with possible rename > divert /lib/system/system/networking.service (with care that it does not > disable ifupdown when ifupdown2 is removed and other possible nuances) > > OR > (b) just introduce the "Conflicts: ifupdown" back > > Is there a deadline for stretch fixes ?. since this bug is marked serious, I > agree with you and we will do the best possible solution for stretch. > Julien is traveling and will look at it as soon as he is back online. No real deadline, but should be fixed ASAP otherwise ifupdown2 will get removed from stretch at some point (with no way of returning), especially if discussion in the bug ends without action afterwards. > Thanks for the review and the discussion. Andreas
