- 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