Restore compatibility with older libaudit/libselinux

[bluca]

The version requirements were bumped, but for example libselinux 3.2 is available in few places (eg: not yet in Debian unstable). But the new functionality is just 4 preprocessor defines, so it's very simple and not intrusive to ifdef them instead. This allows backporting to older LTS distros without having to patch dbus-broker.

Signed-off-by: Luca Boccassi [email protected]

Follow-up for https://github.com/bus1/dbus-broker/pull/251

[dvdhrm]

Can you explain why you want new dbus-broker backported to a distro, but not libselinux/libaudit? You suddenly create a combination that upstream neither supports nor tests.

This patch puts the burden of outdated dependencies on upstream dbus-broker rather than the packager that made the decision, even though we as upstream do not test it nor get feedback when to stop supporting those old versions.

Yes, the patch is rather trivial, indeed. But so far we avoided any optional version dependencies other than to wait for kernel patches to hit upstream. I would like to keep it that way, unless I get convinced it is a stupid idea?

[bluca]

Because libselinux and libaudit are maintained by completely different people, with completely different schedules and plans. It's not just backports, I can't even upload to debian unstable without this change. This stuff is beyond trivial, it's all new featurettes with a fallback that was the status quo for years until a month ago or so, so I'd go as far as saying it's more tested, not less ;-)

[dvdhrm]

This stuff is beyond trivial, it's all new featurettes with a fallback that was the status quo for years until a month ago or so, so I'd go as far as saying it's more tested, not less ;-)

With your change applied and new libselinux but old libaudit you suddenly get audit reports with audit_type=0 but type!=NO_AUDIT. I don't see how this makes sense. I disagree that this change is "beyond trivial". This can be fixed, but my point is exactly that we don't want this dependency-matrix which is really hard to review.

Because libselinux and libaudit are maintained by completely different people, with completely different schedules and plans. It's not just backports, I can't even upload to debian unstable without this change.

I understand. I explicitly waited several months before pulling this change. audit-3.0 was released in Dec-2020 and selinux-3.2 in March. dbus-broker-29 was tagged 3 months later. How long am I supposed to wait for dependencies to settle? How long am I meant to carry workarounds for older versions? People often waive these concerns because the changes look trivial. But then we will pile up these conditional compilations and they will interact, as even this simple case shows.

[bluca]

This stuff is beyond trivial, it's all new featurettes with a fallback that was the status quo for years until a month ago or so, so I'd go as far as saying it's more tested, not less ;-)

With your change applied and new libselinux but old libaudit you suddenly get audit reports with audit_type=0 but type!=NO_AUDIT. I don't see how this makes sense. I disagree that this change is "beyond trivial". This can be fixed, but my point is exactly that we don't want this dependency-matrix which is really hard to review.

I'll fix it tomorrow.

Because libselinux and libaudit are maintained by completely different people, with completely different schedules and plans. It's not just backports, I can't even upload to debian unstable without this change.

I understand. I explicitly waited several months before pulling this change. audit-3.0 was released in Dec-2020 and selinux-3.2 in March. dbus-broker-29 was tagged 3 months later. How long am I supposed to wait for dependencies to settle? How long am I meant to carry workarounds for older versions? People often waive these concerns because the changes look trivial. But then we will pile up these conditional compilations and they will interact, as even this simple case shows.

A few months is nothing, and doesn't serve any purpose, might as well don't wait at all. The minimum is 3-4 years to wait for a full cycle of the major LTSes, better yet 6-7 years to wait 2 cycles. The 2/3 dependencies you have here are a tiny tiny list compared to what's normal, it's beyond trivial to keep track of them.

[teg]

I think we have quite different expectations here. As a general rule, we do not aspire to support more than the most recent version of our dependencies (there are some exceptions).

Mixing and matching new with old software (and most importantly: testing it) would be downstream's responsibility.

[bluca]

I think we have quite different expectations here. As a general rule, we do not aspire to support more than the most recent version of our dependencies (there are some exceptions).

Mixing and matching new with old software (and most importantly: testing it) would be downstream's responsibility.

It is - I am downstream across several distros, hence why I sent this patch. It is a huge waste of everybody's time to force everyone to independently come up with the same trivial fixes for the same trivial problems over and over again.