The current regular expression for matching on Python metadata files was
too greedy, leading to generating dependency information for Python modules
that were actually bundled in another module rather than actually being
installed in a way that is usable and accessible from any Python code
using the system interpreter.
This change tightens the regular expression so that we only match on
modules that are installed in a way that they'll register with
distutils/setuptools based tools (such as pip) and usable as
dependencies for other Python module packages.
Rather than having the pythondistdeps dependency generator run on
all Python code, this separate attr will activate it only if the
package includes Python dist metadata (such as egg-info or dist-info
for Python Eggs and Python Wheels, respectively).
This is much more efficient, too, since the generator is only run
in circumstances where it will provide useful information.
This is based on the dependency generator attr used in Mageia,
OpenMandriva, and other systems that use the generator.
Trying to include AM_CFLAGS through a configure generated rpm.am file
doesn't really work because at the time automake runs configure doesn't
exist yet to process rpm.am.in. Just define the AM_CFLAGS substitution
inside the Makefile.am files themselves.
Rename rpm.am.in back to rpm.am.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
These provides are specifically for packages providing
AppStream files, which are either going to be *.appdata.xml
or *.metainfo.xml files in /usr/share/appdata or /usr/share/metainfo.
The upstream AppStream specification mandates *.metainfo.xml files
installed into /usr/share/metainfo, but there's still a large body
of legacy AppStream files installed in the legacy location.
For now, let's support both under the new metainfo() Provides.
This patch lets debuginfo packages provide build-id like follows:
debuginfo(build-id) = c63cb23876c5fa85f36beaff58f8557e1bf22517
Originally this patch was written by Jan Blunck <jblunck@suse.de>.
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
Appdata files contain application information used by the AppStream
project. We generate two provides: appdata() to support enumeration
of all application packages and appdata(filenname) to make it easy
to link installed packages with appdata files.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Newer file is more eager to flag files as Perl module source,
causing false provides to be generated. Require both magic
and path to match for perllib classification to reduce the pain.
- libmagic sometimes adds trailing descriptions about encodings, line
terminators and whatnot, we dont want to care about those (RhBug:796218)
- not all python-related strings start with [pP]ython either, sometimes
libmagic says "a python script" or "a /usr/bin/python script" and
whatnot, so loose the start-of-line restriction as well
- file 5.10 has changed magics at least for perl and python scripts, samples:
5.09: a /usr/bin/perl -w script, ASCII text executable, with very long lines
5.10: Perl script, ASCII text executable, with very long lines
5.09: a /usr/bin/python script, ASCII text executable
5.10: Python script, ASCII text executable
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Somewhere between file 5.05 and 5.07 it started adding encoding
to script descriptions, eg "<mumble> script text executable" became
"<mumble> script, <encoding> text executable" breaking what had
been working for 10+ years in the case of old find-requires.
- Permit either comma or space after "script", this works for both
old and new file.
- Regression from the initial conversion to the new system in
commit 8c7e53ec80
- The buildroot doesn't need passing as arg anymore but for now,
just keep it compatible
- Dumb attribute vs macro name thinko/typo preventing it from working
at all, duh.
- At least for now, revert back to magic based pattern: we dont really
know where all the perl modules might live. OTOH this relies on
the ugly "all .pm files are perl modules for now" hack inside rpmfc.c.
We could of course use a loose /.*\\.pm path rule too for the same
effect and eliminate the hack, but that'd leave strange stuff into
fileclass tags when libmagic fails to detect its actually perl.
Need to figure out something better here... maybe allow overriding
libmagic detected strings from foo.attr or such.
- move most of the hardwired classification logic from rpmfc C-code
to macro-based configuration, supporting drop-in addition of arbitrary
new attributes + dependency extractors based on regex matching of
libmagic file types and paths
- just the initial rough conversion of our built-in dependency types,
various open questions + todo-items remain, plus likely fair amount
of more-or-less subtle breakage
Panu Matilainen