-
Notifications
You must be signed in to change notification settings - Fork 12
Add rpm fileattr generator for dlopen-notes #53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Fedora doesn't allow |
| # 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
a2bcb9c to
9f6142b
Compare
|
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 |
|
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. |
|
Ah, indeed. @bluca wdyt? Anyway, any relicensing of existing stuff should happen in a separate PR. Not a blocker for this one. |
|
Yeah that should be fine |
No description provided.