- These were used, back in the day, to implement a hidden --specedit
switch, which in all its glory did: print a copy of a spec file,
with group, summary and description looked up from specspo.
This huge pile of junk was left behind from kicking out the
useless "feature" in commits 7b95061d3b and
0f991a1420.
- rpmParseState uses might actually qualify for a true enum here
but changing it would require changing half of librpmbuild and
many of them mix the parse states, other error codes and whatnot
in their types... just not worth the trouble, so use an int.
- The string from getStringBuf() is not modified, so use a const
variable for it, and a separate variable for the temporary
line splitting for triggers
- addChangelog() is a bad boy and modifies the string it grabs
from getStringBuf(), be clean about it and grab a copy through
argvJoin() instead
- addChangelog() would be better off walking and parsing over the
argv directly instead of a joined string of it all, but leaving
that exercise for some other rainy day
- Similar to commit 1e3db59b56,
no point using temporary string buffer when only end up splitting
it into an argv for processing. Incidently this would've been
a much less intrusive fix to RhBug:573339 than introducing
a whole new argvSplitString() function... oh well. Take care not
to introduce extra newlines in the process as argvSplitString() was
eating them before - need to use appendStringBuf() for spec->prep now.
- Callers know perfectly well which part they're passing to doScript()
so they can just as well pass in the name and the scriptlet to run,
avoiding silly stuff in the switch-case
- Similar to commit 1e3db59b56,
all these end up being passed to argvSplit() to process them line
by line in the end, collect them in the argv to start with saving
a whole lotta huffing and puffing in the process
- Collect the filenames directly into the ARGV_t files instead of
putting them to a StringBuf first and then argvSplit()'ing the
result, doh. Leftover stupidity from eliminating splitString()
usage in commit 94ff22b129
- Nobody in their right mind is likely to be calling what's really
an internal helper function in the build code. Simply missed in
the first round of librpmbuild API butchery.
- This eliminates the last remaining exposure of StringBuf in the API
- Many of these cases would be true enums from preambleList & similar,
except for the list terminating sentinel. Just switch all the
remaining rpmTag's to rpmTagVals to bring our enum-whacking to
a grande finale.
Spec files have a lot of metadata about a project. However one of the
most key components is the upstream version control system which was
notably lacking.
Resolve this by adding a "VCS" key. There is no specification
for contents of this key, given that the set of version control
systems (and features thereof) are not well-defined. However,
recommendations are:
* git: This URL should be in a form that can be passed to "git clone",
with the additional feature that an optional fragment identifier "#foo"
denotes a branch or tag.
- Handle source rpm query as a new query source type RPMQV_SPECSRPM,
rename the binary query to RPMQV_SPECRPMS, with RPMQV_SPECFILE
as a backwards compatibility alias to RPMQV_SPECRPMS.
It appears the access to the source header has started to get buried
into usability so add an getter so the implementation can change a
little without breaking callers.
- Iterators for both (these could easily done as self-iteration over
->next but to keep the api similar to other rpm iterators...)
- Minimal getters to satisfy python bindings needs
- These huge structs have no business being visible to the public.
Just brute-force split all remaining spec internal structures into
another internal header, including where needed.
- The only thing accessing these structs outside of librpmbuild is
the python spec bindings. Temporarily permit direct access to
rpmspec_internal.h until we have the necessary API in place.
- This is not really native rpm code but a copy of (glibc?) FTS
implementation, with slight modification to avoid symbol name
collisions. Stick it where the sun don't shine, we'd eventually
like to get rid of such bundled external code.
- Similar in spirit to commit 825691afb2,
these have fairly little in common really.
- Change the function names to force breakage on users (these are exported
in ABI but not in public headers so "users" are internal uses in
practise): the automatically generated bits in signature header are
not signatures, but digests (even size is a checksum of sorts) ...
and fix the couple of internal uses.
- Been 2.5 years now without seeing that trap trigger, should be safe
to remove now ... to silence a warning about comparing to non-existent
enumeration value.
- Enums are fine for defining the bitfield flags, but the bitfield
itself is not an enumeration. Add a separate typedef on "rpmFlags"
type (presenting a bitfield of flags) for all of these. Compilers
hardly care, but the typedefs give a nice visual clue for
us humans using these flags far away from ho^H^H definitions.
- Not needed by rpmbuild itself currently, but permits retrieving the
build dependency information in a format that's better suited for
further processing than an rpm problem set.
- Add new public rpmSpecCheckDeps() function which can be used for
checking build dependencies of a spec against a transaction set.
- Change checkSpec() in rpmbuild cli to use the new interface
- rpmbuild.c is now free of direct spec structure accesses
- Spec parse flags are specific to parsing a spec, not building it.
This could be relevant again if a higher level build API is added
to the library but not ATM.
- Targets are obviously relevant for building but not in the
context of rpmSpecBuild which expects the environment to be set up
already. If/when we add a higher level build interface to librpmbuild
this comes relevant again, until then bury inside the cli-tool.
- Simplify the target parsery by using argvSplit() and friends.
- The mode letters are only relevant for the rpmbuild cli tool. If/when
some of the related build logic is moved from the cli tool to the
library, we'll need a better way of expressing these combinations
than letters.
- Transaction set verification bits are not relevant to building,
bury inside the rpmbuild cli utility.
- Also the type was wrong, its rpmVerifyFlags, not rpmQueryFlags, duh
- Add another flag set to control package generation, passing around
as necessary. Use this to implement --nodirtokens functionality
in a cleaner manner.
- Call freeNames() at end of buildSpec() instead of requiring API
users to clean up after us. This does mean losing some of the
supposed caching advantage when building on more than one spec,
but hardly matters, one spec at a time is the typical build usage
anyway.
- For now just a wrapper around parseSpec() that returns *gasp*
a pointer to a parsed spec structure.
- Limit the amount of goo that needs passing - optimally we'd only need
the spec + parsing flags, but due to %{buildroot} macro abuse in specs
we'll need that for now too.
- This was broken for years without anybody complaining, should
be safe to conclude nobody will miss it later either. And if
somebody misses it, this is a job for rpmlint really.
- The whole rootDir seems dubious for build purposes, but in any case its
only relevant during the actual build process, not for spec parsing.
Set spec->rootDir from buildSpec() for the duration of the
build to avoid having to refactor doScript() and all right now.
- Cookies are not a property of spec but a given build, handle this
internally to buildSpec() except for --rebuild which passes the
srpm identifier cookie through buildArgs
- Accept the entire build arguments structure along with a spec, these
contain everything that we'll need
- Just a convenience wrapper for buildSpec() for now, more things
to follow...
- Update the sole existing caller accordingly
The %sepolicy section is used to describe SELinux policy to be included
in a package. It's syntax is similar to other sections (%files, %pre,
%post, etc.) in that you can provide a string and -n after the
declaration to specify policy should be added to a subpackage.
For example:
%sepolicy
# policy in this section will be added to the main package
%sepolicy foo
# policy in this section will be added to the '<mainpackage>-foo' subpackage
%sepolicy -n bar
# policy in this section will be added to the 'bar' subpackage
The %sepolicy section contains zero or more %semodule directives, with the
following format:
%semodule [OPTIONS] path/to/module.pp
The available options are:
-b, --base
The module is a base module
-n, --name=NAME
The name of the module. If not given, assumes the name is the basename of
the module file with file extensions removed.
-t, --types=TYPES
One or more comma-separated strings specifying which policy types the
module can work with. To explicitly state that a module can work with any
policy type, "default" can be specified as the value. If not specified,
assumes the module can work with any policy type, and assigns the types as
"default".
Below is an example of this new format:
%sepolicy
%semodule -n foo -t mls policy/foo.pp
%semodule -n bar -t strict,targeted,mls -b policy/bar.pp
This also adds new header tags to store the new information:
RPMTAG_POLICYNAMES (string array)
RPMTAG_POLICYTYPES (string array)
RPMTAG_POLICYTYPESINDEXES (uint32 array)
RPMTAG_POLICYFLAGS (uint32 array)
The index of NAMES and FLAGS maps directly to the index of RPMTAG_POLICIES.
However, because a single policy can have multiple types, the mapping for
TYPES is not direct. For this, the index maps to TYPESINDEXES, which
contains the index of the policy that the type maps to. This is similar to
how DIRINDEXES is used to map DIRNAMES and BASENAMES. As an example, the
previous %sepolicy section would have the following header tags:
RPMTAG_POLICIES:
0: <foo.pp data, base64 encoded>
1: <bar.pp data, base64 encoded>
RPMTAG_POLICYNAMES:
0: foo
1: bar
RPMTAG_POLICYFLAGS:
0: 0
1: 1 # assumes flag 1 == BASE
RPMTAG_POILCYTYPES: RPMTAG_POLICYTYPESINDEXES:
0: mls 0: 0
1: strict 1: 1
2: targeted 2: 1
3: mls 3: 1
- Fixes the long standing obscure behavior of missing %files
section causes build to complete without errors but without producing
any packages either. Packages without files in them are perfectly
valid (eg metapackages), requiring empty %files section for those
is just unnecessary spec noise.
- Remove %files section on one of the test-suite specs to create
a test-case for this as a side-effect.
- This of course introduces a slight incompatibility with older rpm's,
if compatibility is required then just add those empty %files in the
spec, they dont hurt anything but the readers eyes.
- Combining description /checking/ and arch/os/platform /adding/
into same for-loop (to save cycles or lines, dunno) makes no sense
whatsoever. No functional changes.
- All these are internal implementation details that no callers
should mess with. Bury inside rpmbuild_internal.h.
- spec, package and source structures are tougher nuts as python
bindings expect to expose some of the information, we'll need
at least some api to cover walking over package headers etc before
shutting the door completely.
- Yank everything qualifying as "internal helper function" into
internal-only headers, loosely grouped as follows:
1) Everything involving spec-manipulation goes into rpmbuild_internal.h
2) All other miscellaneous helpers go into rpmbuild_misc.h
- This leaves us a rather minimal, and nearly useful API into librpmbuild:
Users need to be able to parse a spec, query or build (parts of) it
and free up the spec structure when done. This is what we have now,
various still exposed structures not counting.
- The only thing that should ever call this is freePackages() which
was already made static. As newPackage() links the package structure
with the spec, its not safe for others to call it.
- This is a funky little implementation detail which no caller should
have to bother with. Move it to parseSpec.c which is the only place
needing it now and make static.
- processSourceFiles() is only ever called through buildSpec(),
and if you throw unparsed spec into that you're pretty much screwed
anyway. rpmbuild always called initSourceHeader() anyway, and now
its ensured for all successfully parsed specs.
- This is where it logically seems to belong to, after all parseSpec()
similarly populates all other metadata of the binaries etc too.
No point requiring callers to do this obscure extra call.
- processSourceFiles() is more about processing the physical files
ending up in the srpm payload, source + patch tags are mostly just
informational and can be added early
- readRPM() is not used or needed by anything, shred it
- make writeRPM() static inside the only place needing it: pack.c
- move struct cpioSourceArchive_s inside pack.c
- Signing is better done in an environment completely separated from
the process of actually building packages. This is how its generally
done anyway by distros, this change just forces the issue.
- While signing on build seems handy and saves some io-churn, this
is very insecure as your precious secret passphrase remains unencrypted
in memory for the entire duration of the build where it's accessible
to whatever happens to be building. This change doesn't
affect fix the issue of unencrypted passphrase residing in memory
and potentially getting swapped out, it only limits the exposure
to the actual signing process which isn't subject to unknown scripts
poking around.
- Minimally preserve rpmbuild's --sign functionality via popt --pipe hack
to call rpm --addsign when build completes
- Use a self-pipe to handle signal race on select(). pselect() would work
too but this is more portable and avoids other signal hassles.
- Use non-blocking IO for communicating with the child to avoid spin-happy
timeouts, just check all fd's properly before trying to use them
- Avoid leaking memory from readBuff on errors
This patch allows short-circuiting of building binary packages. To
prevent accidental use of short-circuited rpms, they are marked with
an unsatisfiable dependency "rpmlib(ShortCircuited)". A developer using
this feature for local development and testing will use "--nodeps".
Should such a rpm leak into the world, users will quickly notice
it does not install by default.
(v3: avoids API change, suggested by Panu Matilainen.
v2: added poisoning with unsatisfiable dependency.)
Michal
- Forgot how nasty hack parseBits() was... its abusing multilang
support and the multilang support passes "C" if no lang is specified,
which certainly isn't a valid qualifier. Make multilang vs tag with
optional qualifiers different types in PreambleRec, which allows
handling this more sanely
- Additionally build-dependencies dont take any qualifiers now
- A pre-transaction dependency is generally anything that must be
available at the start of the transaction, and cannot be resolved
by packages *in* the transaction. This lets %pretrans scriptlet
dependencies be expressed correctly, and could be also used for
other kinds of pre-conditions.
- rpmlib() dependencies are a special case of pre-trans dependencies
but leaving them handled separately as they cannot be provided by
anything in rpmdb either, whereas pretrans dependencies can.
- previously unknown qualifiers would go unnoticed if they happened
be last (including being the only qualifier), eg Requires(pre,junk)
or Requires(junk) would be cheerfully accepted but Requires(junk,pre) not.
- Rpm has never done anything useful with "BuildRequires(prep): foo"
style dependencies other than recorded them in src.rpms, nor is there much
point in properly supporting this in the future either
- Frees up four more bits from rpmsenseFlags for better uses
- pass the wanted dependency type to addReqProv() as tagN argument
(previously unused, eh...) instead of taking up three precious bits
for internal-only purposes from a constrained bitfield
- 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
- 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
- OCaml seems to have fairly well detectable magic in its files, nice
- Dont call the regular find-requires from the scripts now that internal
is working
- patch from OpenSUSE / Michael Schroeder
- build-time generated file lists should be placed in the build directory,
but at least one valid use case for this is things like %files -f %{SOURCE10}
- extract mime handler capabilities from application .desktop files
- extract font family names and supported languages from font files
- both are used by PackageKit for on-demand installing of fonts and
applications, but are useful for other things too
- disable "known tokens" lookups in ascii files, this is way too unreliable
to do anything but cause pain
- consider text files as RPMFC_TEXT consistently
- font metrics files are not fonts
- prerequisite for various things like font provide extraction
- at least libmagic from file-5.00 leaked fd's with MAGIC_COMPRESS,
this has been fixed as of file-5.03
- Broken by commit af8b41c64a which
simplified too much.
- There's no guarantee that rpmdsNew() returns a sorted dependency set
so rpmdsFind() doesn't work correctly here. Walk the ds manually instead.
- With multiple triggers of same type, identical trigger conditions on
different trigger script were seen as duplicates (RhBug:490378)
- Split the duplicate checking to separate helper function for clarity
- parseSpec() operates on newly created empty spec structures even when
"recursing" but the lua variables are global and need recursion
protection to avoid adding multiple times
- avoids silly clutter in every specfile in the regular case but permits
overriding if needed for whatever reason
- it's a spec behavior change but mostly backwards compatible:
existing specs will do whatever the %clean does, and if you need to avoid
calling %clean for whatever reason just keep an empty %clean in the spec
- RPMTAG_POLICIES is a string array but there's no guarantee that
something marked %policy is a plaintext file that can be represented
as \0-terminated string, base64-encoding them fixes that. Baby steps
towards making %policy remotely usable, related to RhBug:505066.
- Also remove unnecessary failure code setting, processMetadataFile()
assumes failure already, and dont try to insert NULL strings in case
b64encode() or pgpArmorWrap() fails
- regression from commit 899dfb5892,
size of hardlinked file set is the size of one file of the set
- add isHardLink() internal helper to avoid a copy-paste code
- "lzma alone" is superseeded by XZ but it's used by Suse and Mandriva
distros so it's nice to have as it doesn't need much, only open differs
from XZ
- rpmlib() dependency versions are an uuuuuuuugly mess here: Suse used
"PayloadIsLzma = 4.4.2-1" so that's what we provide to be most compatible
(hopefully). Built packages require "PayloadIsLzma <= 4.4.6-1" however
to be compatible with Mandriva 2008.0. Did I already say it's ugly?
- Based on similar patch in Mandriva by Per Øyvind Karlsen, but avoiding
unnecessary renames in rpmio
- what we support now in payloads is XZ, not the former LZMA format, rename
user- and header-visible parts to match this
- rpmlib(PayloadIsXz) dependency versioned 5.2-1 to avoid unnecessary
incompatibility with what rpm5 has and what Mandriva is already using
- only provide the rpmlib dependency if actually built with xz support
- rpmFileIsCompressed() attempts to guess the magicless old lzma format
by file suffix, so it can handle both right now
Panu Matilainen