There's some confusion when and how exactly the %license fallback macro should be defined. https://fedorahosted.org/fpc/ticket/411#comment:11 is wrong, and https://fedoraproject.org/wiki/EPEL:Packaging#The_.25license_tag is not as well visible as it should be.
Proposal: change https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
If the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %license. If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake.
to
If the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %license. The %license macro is available in Fedora, and a fallback can be provided for old EPEL, see [[https://fedoraproject.org/wiki/EPEL:Packaging#The_.25license_tag EPEL guidelines]] for details. {{{=== Missing license file ===}}} If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake.
This adds a separate subsection for the "missing license" part.
First off, we try to keep EPEL-only things out of the main guidelines, and I object generally to saying things like "the macro is available in Fedora" when that should obvious from the fact that they're in the Fedora packaging guidelines. I don't see how EPEL specific guidelines are any less visible than regular guidelines in general, since those packaging for EPEL should be familiar with the EPEL policies. Maybe the EPEL pages can mention their guidelines more prominently. They're not access-controlled so feel free to edit them as you wish.
Perhaps we could refer to them in one place near the top of the main guideline page and leave it at that.
Secondly, the EPEL-specific macro will not be required in the relatively near future, at least for EPEL6, since the epel-macros package defines it (using magic to get it defined at the proper place) and that will be in the default buildroot.
In my experience people prefer to use a single spec file for all branches (including EPEL), so they often add the fallback definitions already in the master branch. I saw the incorrect fallback definition being used a lot. In fact, if they tried to build the package for EPEL it would fail, so it's pretty certain that they are building for Fedora only. Adding the link to EPEL macros from the Fedora guidelines might thus be useful.
Anyway, I'm not strongly convinced myself. Feel free to close this ticket, or add a link at the top.
I think the incorrect form of the definition (with '%%doc' not '%doc') is a significant issue that needs to be addressed. I suspect it's present in a lot of packages. Here are just the ones I happen to have checked out and up to date:
{{{ ./coreutils/coreutils.spec ./dbus/dbus.spec ./dhcp/dhcp.spec ./dracut/dracut.spec ./e2fsprogs/e2fsprogs.spec ./fedfind/fedfind.spec ./fedora-release/fedora-release.spec ./gcc/gcc.spec ./generic-release/generic-release.spec ./glibc/glibc.spec ./grubby/grubby.spec ./initscripts/initscripts.spec ./inkscape/inkscape.spec ./libblockdev/libblockdev.spec ./libffi/libffi.spec ./mesa/mesa.spec ./nss/nss.spec ./openssh/openssh.spec ./openssl/openssl.spec ./p11-kit/p11-kit.spec ./php-Assetic/php-Assetic.spec ./php-bantu-ini-get-wrapper/php-bantu-ini-get-wrapper.spec ./php-doctrine-dbal/php-doctrine-dbal.spec ./php-google-apiclient/php-google-apiclient.spec ./php-opencloud/php-opencloud.spec ./php-patchwork-jsqueeze/php-patchwork-jsqueeze.spec ./php-PHPMailer/php-PHPMailer.spec ./php-Pimple/php-Pimple.spec ./php-ZendFramework2/php-ZendFramework2.spec ./pion-net/pion-net.spec ./policycoreutils/policycoreutils.spec ./python-cached_property/python-cached_property.spec ./python-cairocffi/python-cairocffi.spec ./python-requests/python-requests.spec ./python-wikitcms/python-wikitcms.spec ./roboptim-core/roboptim-core.spec ./roboptim-trajectory/roboptim-trajectory.spec ./sddm/sddm.spec ./selinux-policy/selinux-policy.spec ./shadow-utils/shadow-utils.spec ./syslinux/syslinux.spec ./texinfo/texinfo.spec ./util-linux/util-linux.spec }}}
some of those are my own packages and I can fix 'em, but others aren't. we probably ought to have an automated fix+rebuild of all packages with the incorrect definition.
I thought so too, but don't think it's causing actual problems. If you try to build a package on EPEL with %%doc things fail completely. So incorrect macro in all those packages most likely means that compat with EPEL was added but never used. When people try to build such a package on EPEL they will notice and get a chance to fix it.
OTOH, it is worthwhile to stop it from spreading further. I don't know if people are more likely to take the macro from guidelines or copy from another package. In my experience the latter is much more frequent. An automated fix makes a lot of sense. But there's no need to rebuild. I'd just fix the macro definition without bumping release or touching changelog.
Oh:
{{{ rpm-specs $ grep -F '%{!?_licensedir:%global license %doc}'|wc -l 400 rpm-specs $ grep -F '%{!?_licensedir:%global license %%doc}'|wc -l 758 }}}
Does anything need to happen here or just a lot of bugs need to be created?
What, exactly is wrong with the %%doc form? The both seem to work fine for me in EPEL6.
A version of epel-rpm-macros for epel6 which defines %license should be in stable with the next push, but that needs to get added to the buildroot. There's a chance I might be able to do the same for epel5, which would completely obviate the need for this macro in any spec.
It would have been a thousand times easier if they had just used %lic for the name of the directive, ugh.
In the meantime, since getting it added to the buildroot might take some time or meet some resistance, I don't see a problem with someone fixing these up, but maybe we could wait a bit (since it isn't really hurting anything at the moment) and perhaps we can just remove them entirely. Otherwise, yes, having exactly one version would be good in any case.
Does it actually matter? At least with the RPM in EPEL6, they're actually the same thing in most cases. In a macro definition (as well as several other contexts, but oddly not directly in %files) attempting to expand an undefined macro results in the string not changing. So %doc expands to %doc, as long as there's no %doc macro defined, a we know that %% turns into % so %%doc expands to... %doc. I think the double percent form is technically more correct but I don't care either way (and what we have is one character shorter).
Replying to [comment:7 orion]:
I stand corrected. You are right, both versions work just fine. The error reported in #411 was caused by defining %license before License.
In the light of this, and the fact that the fallback will not be needed soon anyway, I'll close the ticket.
Login to comment on this ticket.