search

bus1 / dbus-broker

Linux D-Bus Message Broker
https://github.com/bus1/dbus-broker/wiki
Apache License 2.0
667 stars 78 forks source link

Restore compatibility with older libaudit/libselinux #273

Closed bluca closed 1 year ago

bluca commented 2 years ago

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 bluca@debian.org

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

dvdhrm commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.