That depends on what files are built from what source. If anything in the main
package is actually built from lib or rpmio dirs, the License would be
`GPL-2.0-or-later AND (GPL-2.0-or-later OR LGPL-2.1-or-later)`, based on the
"no effective analysis" rule, wouldn't it? (Silly, isn't it?)
--
Another Fedora package is known to be impacted. python-quantities:
https://bugzilla.redhat.com/show_bug.cgi?id=2213013
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2532#issuecomment-1579523314
You are receiving this because you are
(see #2078 for further background)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2532#issuecomment-1578622766
You are receiving this because you are subscribed to this thread.
Message ID:
Yeah, I see this is a problem. The fact that we don't really have a proper
directory for the build is really not great. We basically rely on the source
tarball providing a directory (*). Having the directory beside the buildsubdir
is probably the best solution for now until we move the whole
> ... The conclusion is that something similar must be done before calling
> getopt in rpm to process macro parameters with quotes.
There is already a function named
Hmm, reading again the COPYING:
```
Alternatively,
all of the source code in the lib and rpmio subdirectories of the RPM source
code distribution as well as any code derived from that code may instead be
distributed under the GNU Library General Public License (LGPL), at the
choice of the
> So no, it wont work in rpm 4.14.
Since this version is still the default version on openSUSE Leap 15.4/15.5, I
tried to implement the above example for 4.14 and came up with the following
script based on [rpm
macros](https://rpm-software-management.github.io/rpm/manual/macros.html):
```
cat
