Bug#975554: udev and systemd version should always be in sync

[Ansgar]

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