- 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
This adds two basic tarballs, one containing two minimal executables
(foo & bar), and one contain a simple policy for the two executables.
This also adds a new spec file with a policy subpackage, the new
%sepolicy section, and the sepolicy collection.
This adds a new plugin specifically for a collection to load SELinux
policy. This implements the post_add and pre_remove plugin hooks. The
only time anything happens during the pre_remove hook is if post_add was
not called (i.e. if the transaction only removes policies).
This plugin extracts all the policy information from packages in the
sepolicy collection during the open te hook. It then determines which
policies should be installed/removed based on if the package is being
installed/removed and the type of the policy and the system policy. It
then executes semodule (or uses libsemanage if semodule cannot be
executed or installing in a chroot) to remove and install the necessary
policies. It then reloads the selinux state, reloads the file contexts,
and if necessary, relabels the file system.
This replaces the old matchpathcon interfaces with the new selabel
interfaces for relabeling files, storing an selabel handle in the
transaction set.
With this change, also comes an added distinction between --nocontexts
being specified and a failure to read the load file contexts.
Previously, there was no distinction, and both cases used the
RPMTRANS_FLAG_NOCONTEXTS flag.
However, with the new policy plugin, it is necessary to make such a
distinction. This is because matchpathcon_init (now selabel interfaces)
can fail at the beginning of the transaction, but succeed later after
new policy is installed. Because of this, we may need to enable/disable
RPMTRANS_FLAG_NOCONTEXTS multiple times. However, because this flag
could also mean --nocontexts, we cannot do that. By storing the selabel
handle in the rpmts, we can easily keep track if the handle has been
successfully created, rather than overloading RPMTRANS_FLAG_NOCONTEXTS
with two meanings.
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
This moves most of the plugin logic to a new rpmplugins file with a
struct and functions for managing plugins, allowing for plugins to carry
state. This also adds init and cleanup hooks for plugins to initialize
and cleanup their state, and a new 'open te' hook allowing plugins to
read and save information from transaction elements.
This also generalizes the plugin architecture a bit so it isn't so
specific to collections.
- 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
Panu Matilainen