Michael Biebl writes:
> Am Montag, den 23.11.2020, 15:38 +0100 schrieb Ansgar:
> As mentioned in another MR [1], the imho most "elegant" way would be an
> artifical libsystemd0 dependency in udev.
Ah, yes, I remember you asked about something like this, but couldn't
find where :)
> Breaks and Conflicts have a tendency to cause weird results, so I'd
> like to avoid them as much as possible.
I agree; people uninstalling udev by accident is probably not good...
>> Maybe udev should have
>> "Breaks: systemd (!= ${binary:Version})"? But I'm not sure if that
>> might result in apt suggesting to remove udev instead.
>
> Shouldn't this be the other way around, i.e. systemd having a
> Breaks: udev (...) to force udev being upgraded along side.
Not sure. I would hope udev having "Breaks: systemd (!=
${binary:Version})" and systemd having "Breaks: udev (!=
${binary:Version})" to behave similar.
> Have you tested the other combination as well (udev 247 + systemd
> 246)?
No, just new systemd with old udev. And not intentionally, but just
because I ran `apt -t experimental install systemd` or such.
> v247 is a bit of a special case with the (incompatible) sticky udev
> tags change. And maybe restricting it to that version is sufficient.
>
> I guess I'd be fine if we had systemd with a Breaks: udev (<< 247~)
> dependency.
That's probably fine given you would like to be able to test having
systemd/udev not in sync. I don't have a strong opinion on this.
Mostly the packages should be in sync either way (as any suite should
contain the same version of systemd & udev), just when one installs
systemd from a suite with non-standard priority like experimental or
backports one might get out-of-sync. Or when something else blocks one
of the two updates.
Ansgar
