- Add per-scriptlet type flag tags to control special behavior.
- Add rpmlib dependency on scriptlet expansion - if a package relies
on scriptlet expansion it cannot be correctly installed with
a version of rpm that doesn't support it.
- Expansion is always an opt-in behavior, enabled with -q and/or -e argument
in spec. We can't just blindly expand even macros as there's no telling
%{} constructs might mean in whatever language is used for the script.
- Queryformat expansion requires great care with strange and ugly escapes
when writing scriptlets, but OTOH it permits access arbitrary header
data at runtime, which has previously been completely impossible.
- The handling of these expansions needs unifying for all scriptlet types,
the trigger scriptlet handling is uuugly. Macro expansion could be
transparently done from rpmScriptRun(), but because of their similar
syntax, macro expansion needs to happen before query format expansion,
and we dont have the header available in rpmScriptrun()
- Previously we required a file to be classified as text and have
.desktop suffix, for now replace that with just a regex. We'll eventually
want/need some extra qualifying logic to handle cases like these,
eg "only apply path attributes if condition X is also true"
- No functional changes, just clearing the naming conventions to avoid
having to extra mapping for attribute -> extractor name. The current
font provides are handled by fontconfig, but that's just an internal
implementation detail.
- pythondeps.sh knows how to figure python(abi) provide from
/usr/bin/pythonN.N version but as that's an ELF file, pythondeps.sh
never got a chance to run on that file
- Use a table of regex pattern - attribute list pairs to apply any
additional path based attributes. While the fundamental type of a file
certainly does not depend on its location on the filesystem, its
location *does* have attached semantics and it'd be just silly to
ignore that fact.
- The current implementation is dumb as it ends up recompiling the regexes
and splitting the attr strings a million times. OTOH compiling the
regexes into the static rpmfcPathTable would be wrong as the patterns
can contain macros and they can vary from package to package when building
several packages on one invocation. The attribute split + regex compilation
should be done once per rpmfc instanciation...
- No functional changes, just making more obvious mapping between
attributes and the dependency extractor names. This also leaves the
term "interpreter" free for use for the actual interpreters, such
as interpreter(python) provides if we go that way (ticket #136).
- looking at file colors still works as every relevant type has
RPMFC_INCLUDE set but this includes various things we might not have
attributes for, just avoids unnecessary work and is more obvious this way
- should really have been in commit ad2c8485ea
- 32 bits are nowhere near enough to meaningfully classify all the
types of data we might want to extract dependencies for, the bitfield
was already almost used up and twisty with embedded enumeration in the
middle etc. With text-based tokens, there are no limits to the total
number of known attributes or number of attributes that can be attached
to a given file. This also paves way to moving the classification table
out of librpmbuild into configuration file(s).
- Remove most of the now unused RPMFC_FOO definitions from the FCOLOR enum,
leaving just the more abstract INCLUDE, WHITE etc which control other
aspects of the operation. Also ELF is special as the value ends up
in headers, preserve it too.
- Elf dependency extraction code code lifted from rpmfcELF() and refactored
to saner pieces. Having it in separate executable also frees librpmbuild
of libelf dependency, clean up the unnecessary linkage etc from
autofoo
- This lets internal dependency generator for elf files be
overridden without losing file coloring (which is required for
correct multilib handling). It also permits non-native elf files
(eg when cross-building) to be handled by providing a custom
elf dependency helper
- On the flip side, this inevitably slows down builds somewhat as
two fork-exec's are needed for every elf file, but unlike invoking
something like the python interpreter, this is a slim helper...
- All dependency extractors of the internal dependency generator are now
external helpers (how twisted is that, huh? :) and thus can be customized
and filtered through %__foo_provides|requires macros
- permit overriding/customization of script interepreter dependencies
- unlike the C-version, the interpreter.req only looks at the first line
for shebang: libmagic only looks at the first line too, so anything
else will never get classified as scripts in the first place
- loosen up the perl token to catch more things, such as
"/usr/bin/perl -w script text"
- remove unnecessary /usr/bin/python token, these get caught by "python "
already
- remove what now should be unnecessary coloring by interpreter name,
both perl and python scripts should get colored by the tokens already
- Concatenating to global, non-namespaced tag macros is fundamentally
broken for specs with sub-packages, RhBug:555926 is not fixable with
tag macros tweaks.
Revert back to the old behavior where tag macros are simply "the last line
seen wins." This might not be what one expects in many cases but it
is at least consistent, and changing the behavior in any
way (such as not adding the macros for multiline-items like requires)
breaks existing packages without a good reason.
- Correctly handling the expected %{obsoletes} etc behavior in RhBug:555926
would require a new mechanism, such as permitting spec to access the
(sub-)package headers. Probably doable, unlikely to be worth the
effort as the issue can be easily avoided by writing the spec differently.
- This reverts commits 3be37d9c78 and
e811ef56aa
- move the includes out of system.h, not commonly needed
- <poll.h> is conditional as we actually provide a fallback through select(),
but for <sys/select.h> missing there's no fallback so doesn't make
much sense to test for (and both poll.h and sys/select.h are posix anyway...)
- For now, let %{} characters through our valid character set checks
on specs. This isn't right really, but unexpanded, unrelated macros
in spec can now cause failure to parse out buildrequires which would
allow those macros to be expanded. This needs a better fix.
- while the "really public" API of librpmio has only been enhanced,
librpm and librpmbuild use some supposedly internal bits which *have*
changed considerably, so just to prevent anybody thinking they can
combine librpmio from rpm 4.7 and librpm from this...
- librpmbuild hasn't seen much real change but some (unfortunately)
exposed struct members have changed so...
- librpm is mostly compatible but as rpmal has become internal API,
we need to bump (annoyingly, as nothing actually uses rpmal ... sigh)
- we currently only support creating regular files for %ghosts which
dont exist in the buildroot, but for files that do exist in the buildroot
there's no reason to place such limits (eg its perfectly ok to have
symlinks marked as %ghosts)
- Generally only executable files are critical for dependency extraction,
whereas oddball application data files can cause unnecessary build
failure due to libmagic misdetections etc, so just let non-executables
pass with a warning and mark them as unknown data
- only requires on rpmlib(foo) are allowed
- make sure any rpmlib() foo dependencies have RPMSENSE_RPMLIB bit set,
rpmdeps as external dependency generator can create rpmlib() dependencies
without the bit set, and also any manual rpmlib() deps wont have it
Panu Matilainen