[Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-21.mga2

Mon Jan 16 11:41:34 CET 2012

On 16 January 2012 10:37, Thomas Backlund <tmb at mageia.org> wrote:
+>>>> This is wrong, you're just introducing two different behaviors:
+>>>> - new installations will got drakcut&    systemd
+>>>> - updated ones will keep mkinitrd&    sysvinit
+>>>
+>>>
+>>> How about enhancing urpmi to read prefer.vendor.list during distro
+>>> upgrade? That would solve this issue.
+>>> either by a specific --upgrade flag,
+>>> or automatically when mageia-release-common bumps version, would that
+>>> work ?
+>>
+>>
+>> This is already done. But prefer choice only apply to initial package
+>> installation.
+>
+>
+> Which is why I asked if it should do it during upgrade too ?
+
+OK, there's obviously some confusion here.
+
+There's two different things:
+- preferred apps (read: what is the default choice when several packages
+  answer the some "virtual" require)
+- provides & obsolete tags
+
+That's totally orthogonal and preferred apps just don't apply to upgrading...
+If you install a package requesting eg "web_server" which would provided
+by say both apache & nginx, whatever you choose one manually or through
+automatically (preferred apps) doesn't change that after inital install, only
+provides & obsolete tags matter for upgrading.
+
+What's more, even if that was possible, what you're asking is basically
+replace "forcing systemd & drakcut through requires/obsoletes tags" by
+"forcing them through adding special urpmi code".
+Either way, you would force them...
+
+Anyway, urpmi's  preferred packages is not a super obsolete/require
+tags as explained above.
+
+>> Hard requires are not an issue:
+>> - for systemd if systemd-sysvinit isn't hard required, which was
+>> already the case
+>
+> Doh, I forgot about that it was sysvinit vs systemd-sysvinit and not systemd
+> itself :(
+>
+> so systemd can/must be readded as requires.
+
+Indeed.
+
+
+>> - for drakcut, as alternatives are used
+>
+>
+> Yep. useful as long as there is a mkinitrd on the mirrors.
+
+I think the clean way to go would be to:
+1) rename mkinitrd & sysvinit as mkinitrd-old & sysvinit-old:
+2) having both sysvinit-old & systemd-sysvinit provides/obsoletes sysvinit
+   (dito for mkinitrd-old & dracut)
+
+Then on upgrade, as mkinitrd & sysvinit would be obsoleted by new packages
+(eg: systemd-sysvinit & sysvini-old), urpmi would have to choose one,
+choosing dracut & systemd by default due to prefered list.
+Thus we would achieve both:
+- having dracut & systemd on upgrade too
+- being able to fallback to mkinitrd and/or sysvinit by manually requesting
+  their installation.
+
+Other ways would be to:
+1) have mkinitrd & sysvinit requesting drakcut & systemd-sysvinit
+& adding alternatives to systemd/sysvinit :-(
+
+2) manually adding greater provides to systemd-sysvinit & mkinitrd
+  (error prone & fallback involves manually editing skip.list which may
+  break further upgrading from mga2 to mga3 when mkinitrd & sysvinit
+  will be really dead)
+
+>>> If both dracut and mkinitrd provides mkinitrd, the prefer list must
+>>> contain the one we want by default, wich is what I did here.
+>>
+>>
+>> Yes but you also remove all of the obsolete/provides tag, which prevents
+>> drakcut
+>> to replace mkinitrd on upgrade.
+>>
+>
+> Check again. I only removed Obsoletes, the Provides is still there:
+> http://svnweb.mageia.org/packages/cauldron/dracut/current/SPECS/dracut.spec?r1=194858&r2=196541
+
+Which is useless w/o the obsolete tag.
+Have you checked what happens on upgrade? Does drakcut replace mkinitrd if some
+repo still has mkinitrd?
+Anyway it won't work for systemd as its provide tag is smaller in
+systemd-sysvinit than sysvinit
+
+And it's error prone.
+Also see above, fallbacking involves playing with skip.list which may
+break next upgrade
+(mga2 -> mga3)
+