On Sun, Jul 13, 2025 at 07:11:46AM -0400, Ben Beasley wrote:
> The COPYING file in the source tree is a relative symbolic link
> to LICENSES/LGPL-2.1-or-later.txt.
>
> ben@musicbox:~/fedora/other/mingw-glib2$ fedpkg prep && find .
> -name COPYING -exec ls -l '{}' +
>
> […]
>
> lrwxrwxrwx. 1 ben ben 30 Jun 13 07:41
> ./mingw-glib2-2.85.1-build/glib-2.85.1/COPYING ->
> LICENSES/LGPL-2.1-or-later.txt
> -rw-r--r--. 1 ben ben 1698 Jun 13 07:28
> ./mingw-glib2-2.85.1-build/glib-2.85.1/docs/reference/COPYING
> lrwxrwxrwx. 1 ben ben 33 Jun 13 07:41
> ./mingw-glib2-2.85.1-build/glib-2.85.1/gmodule/COPYING ->
> ../LICENSES/LGPL-2.1-or-later.txt
> -rw-r--r--. 1 ben ben 26445 Sep 12 2024
> ./mingw-glib2-2.85.1-build/glib-2.85.1/subprojects/gvdb/COPYING
>
> The %license macro simply copies the symbolic link into the
> appropriate directory. It does not use something like install(1)
> that would resolve the symlink. In this case, it’s probably best
> just to change both instances of "%license COPYING" to "%license
> COPYING LICENSES/". That way, the relative symlink will work, and
> you will also ship all the other license texts that upstream
> considered relevant.
Oh I see, that makes perfect sense, thanks.
FWIW the glib2.spec file has:
%license LICENSES/LGPL-2.1-or-later.txt
I think generally our policy is to stay as close as possible to the
native package, so that might be better in this case.
> While we’re looking at this, the presence of a LICENSE/ directory
> with additional license texts should be a hint to consider auditing
> the source tree with something like licensecheck(1) to figure out
> whether or not "License: LGPL-2.0-or-later" is really the complete
> license of the binary RPMs, considering that Fedora no longer
> employs effective license analysis[1].
Agreed.
Rich.
> - Ben Beasley (FAS: music)
>
> [1]
> https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis
>
> On 7/13/25 6:16 AM, Richard W.M. Jones wrote:
> >https://bugzilla.redhat.com/show_bug.cgi?id=2379753
> >
> >It's reported that the /usr/share/licenses/mingw32-glib2/COPYING and
> >/usr/share/licenses/mingw64-glib2/COPYING license files are both
> >broken links. However the spec file seems totally normal:
> >
> > %files -n mingw32-glib2 -f mingw32-glib20.lang
> > %license COPYING
> >
> >(https://src.fedoraproject.org/rpms/mingw-glib2/blob/rawhide/f/mingw-glib2.spec)
> >
> >I looked into the %license macro and it seems to involve some internal
> >RPM voodoo. Any idea why it doesn't work here?
> >
> >Rich.
> >
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
