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

Thierry Vignaud thierry.vignaud at gmail.com
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)


More information about the Mageia-dev mailing list