On 2/12/17, 2:10 PM, Andreas Beckmann wrote: > 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.
Thanks Andreas. Will will take action on this soon. Given the sensitivity, I think as you suggested, Conflicts maybe the right fix for stretch.
