Background info: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/OHNVT5S4ZPOB56KAYNCWZOC6W2WAV54C/

Seeing that the same question still pops up 3+ years later, clarification is certainly welcome. Lest we want to repeat ourselves over and over again with no change in result.

:thumbsup:

Since we're now relying on several automation to build up the filelist of a package, is there any check on the final output that ensures a license file is really provided?
I mean, by manually writing the %license files in the spec file it is sure that we're distributing the license within the package, but with automation we may end up in distributing packages without license files if automation fails and it's hard to check without inspecting the final RPM filelist (I doubt anyone is going to check that for every build after a package is reviewed and approved).
(for reference: https://bugzilla.redhat.com/show_bug.cgi?id=2133080#c17 )

is there any check on the final output that ensures a license file is really provided?

Maybe Fedora Review does this. Not sure.

It makes you check, it doesn't check itself.

It would be great to add this information to the packaging guidelines, in particular for Python. Probably there are other exceptions, but this is the most common one.

Yeah, packages for Rust crates also default to absolute paths for %license files if possible (to avoid duplicating those files). It would be great to clarify this in the guidelines.

Honestly I'm not seeing why this is even a question; I don't see anything in the relevant document which even suggests that you can't use absolute files or include %license-tagged files in a generated file list. If I'm missing something, please point out where in the guidelines that is so that I can fix it.

If we have to list everything you can do (instead of things which are either encouraged or discouraged) then we'll make War and Peace look like a pamphlet.

Anyway, I've submitted #1291 which includes an attempt at this clarification as well as a conversion to semantic breaks and some minor fixes.

I think the root of the issue is that in the documentation the %license macro is mentioned all over, stating that the license file(s) need(s) to be marked with that macro. People interpret that, as I did, as an explicit, visible marking of the license file(s) in the %files section.

However with Python (I know other language specific package macros do something similar) this happens behind the scenes when %pyproject_save_files is used. If the Python project has a properly defined license file in the build config, it will be installed into the %{python3_sitelib} directory of the package.

However, this is not transparent. If a license file was installed by the package and marked by %pyproject_save_files can only be seen by either inspecting the source, the buildroot or the resulting package's RPM. I believe this is an issue anyone new to packaging, not fully acquainted with the magic of the macros, is more likely to stumble upon.

With a visible, explicit %license tag present in the spec file, it is clear that the packager included the license file(s). Relying on %pyproject_save_files it is not.

Maybe adding something like:

If %license is not used in the spec file, package reviewer should check the RPM for the presence of license file(s): rpm -q --licensefiles -p $RPM.

But that's more something for the package review documentation. Packagers not knowing about macros setting %license are more likely to include it explicitly in the spec file. That may result in duplicate license files.

Another option, probably not in favor with experienced packagers and macro wranglers, would be to not have macros such as %pyproject_save_files deal with license files and leave it to the packager to do so.

It's a bit unfortunate that %pyproject_save_files hides this as an implementation detail, but I don't think any other solution is better here ...

I'd say documenting that the %pyproject_save_files macro does this if the Python package metadata is correct / complete would go a long way.

But in fact, that's already documented: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_build_macros

The only thing I could imagine making this situation clearer would be to amend this section here

https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text

to explicitly say that having macros mark / include the license files appropriately is of course an acceptable alternative to marking / including them manually.

Oh, I see now that you've already addressed this in PR#1291. Sorry, I'm tired :sweat: I'll look at that PR.

The only thing I could imagine making this situation clearer would be to amend this section here

https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text

to explicitly say that having macros mark / include the license files appropriately is of course an acceptable alternative to marking / including them manually.

This seems reasonable.

It may be that, thinking from first principles, people “shouldn’t” misunderstand this—but practical experience shows that package reviewers do frequently believe or suspect that explicit use of the %license macro with a relative path is required, so having something explicit to point to—especially in the section that seems to be confusing people to start with—should really cut down on the confusion that has been happening.

The language in https://pagure.io/fork/tibbs/packaging-committee/c/9dd2b3fec2e757c94eb5c900bece76a9ede767cd seems very clear to me.

I felt that if we were going to touch this, it would be best to mention the end result that we're after, which is that rpm -qL does the right thing. Everything else is an implementation detail.

I can add a short remark that macros or other spec machinery may do this automatically behind the scenes, and tie that into the rpm -qL remark.

I felt that if we were going to touch this, it would be best to mention the end result that we're after, which is that rpm -qL does the right thing. Everything else is an implementation detail.

I agree.

I felt that if we were going to touch this, it would be best to mention the end result that we're after, which is that rpm -qL does the right thing. Everything else is an implementation detail.

I agree.

Yep, that sounds right. 👍

Adding rpm -qL to fedora-review output seems helpful.

Commit 1a78926 fixes this issue

I think the wording is very clear now. Thanks @tibbs!