Skip to content

Conversation

@keszybz
Copy link
Member

@keszybz keszybz commented Jan 13, 2026

No description provided.

@Conan-Kudo
Copy link

Fedora doesn't allow CC0-1.0 for code anymore, can we change this to MIT? I noticed that the dlopen-notes script is also CC0, so this is a problem there too...

Comment on lines +16 to +19
# The option accepts multiple comma-separated pairs, and can also be
# specified multiple times. Both the subpackage name and feature name
# can be a glob. If configuration is omitted, the priority recommended
# in the notes is used.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that the opts macros are not needed by default? It's a little unclear to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Rewording are welcome, but the last sentence way trying to convey that.

If the package has a file with dlopen notes and does nothing more, then it ends up with deps generated from the notes. The "priority" field, or the "recommends" fallback is used to pick Requires/Recommends/Suggests.

This allows dlopen notes to be turned into appropriate dependencies
automatically. The dlopen_notes.attr file needs to be installed into
%{_fileattrsdir}.

By default, dependencies are generated for all files that have package
notes. I think this is a reasonable default because it makes the whole
feature easier to discover. In more realistic cases, esp. with
multiple subpackages, it's likely that the packager may need to
configure the distribution of dependencies between subpackages.

One shortcoming of the scheme is that everything is per file, so it's
not possible to say that dependencies generated from a feature should
be assigned to a different subpackage. This is how the feature is
designed in rpm.

The opt-out mechanism is a bit clunky. The first option I considered
was to tell the user to undefine
%__dlopen_notes_requires/recommends/suggests, but that requires three
lines of boilerplate. And might not be forwards-compatible if we add
new features in the future. The second option would be to tell the
user to define __dlopen_notes_requires/recommends/suggests_opts to
%nil. But that has similar problems. I think it's nice to have an
obvious oneliner to handle this. Unfortunately, when I tried to use
  %__dlopen_notes_requires %{?_dlopen_notes_generator:%{_dlopen_notes_generator} ...}
  %__dlopen_notes_recommends %{?_dlopen_notes_generator:%{_dlopen_notes_generator} ...}
  %__dlopen_notes_suggests %{?_dlopen_notes_generator:%{_dlopen_notes_generator} ...}
in the .attr file, when the package has %undefine _dlopen_notes_generator,
we still end up with the macro being expanded. Maybe I misunderstood
the macro expansion logic. The approach with 'true' is clunky, but
it works fine.

Thanks to Neal Gompa for the suggestion to use this protocol.

The new interface is new, independent of the existing options
--feature, --rpm-recommends, --rpm-requires that were previously added
to support rpms. Unfortunately, with the fileattr protocol, the
old way to specify information is not useful. Instead of trying
to shoehorn the new metadata into existing options, I think it's
easier to add a new set with clear semantics.
This is a package that "builds" by copying two files: a systemd
library that is known to use dlopen notes and another glibc library
that doesn't have them. It can be built with 'rpmbuild' or 'fedpkg local'.
For example:
  (cd fakelib && fedpkg local && echo 'Requires:' && rpm -qpv --requires x86_64/fakelib-0-1.fc44.x86_64.rpm && echo 'Recommends:' && rpm -qpv --recommends x86_64/fakelib-0-1.fc44.x86_64.rpm && echo 'Suggests:' && rpm -qpv --suggests x86_64/fakelib-0-1.fc44.x86_64.rpm)
@keszybz keszybz force-pushed the dlopen-notes-fileattrs branch from a2bcb9c to 9f6142b Compare January 13, 2026 14:56
@keszybz
Copy link
Member Author

keszybz commented Jan 13, 2026

I changed the new files to use MIT-0. Maybe we should try to relicense everything, but that'd require agreement from contributors (and adjustment of the debian/copyright file) and I don't have the energy to figure this out. According to https://docs.fedoraproject.org/en-US/legal/allowed-licenses/#_allowed_content_licenses, it's fine to use CC-0 for code from before the change, so we don't need to change anything now.

@Conan-Kudo
Copy link

Does CC0 require that? It's an ultra permissive license, so switching shouldn't require anything other than updating the stanzas and the license file.

@keszybz
Copy link
Member Author

keszybz commented Jan 13, 2026

Ah, indeed. @bluca wdyt?

Anyway, any relicensing of existing stuff should happen in a separate PR. Not a blocker for this one.

@bluca
Copy link
Member

bluca commented Jan 13, 2026

Yeah that should be fine

@keszybz keszybz merged commit 144f08a into systemd:main Jan 13, 2026
1 check passed
@keszybz keszybz deleted the dlopen-notes-fileattrs branch January 13, 2026 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants