- Except for four rpmbuild tests which rely on an actual compiler
being available (faking *that* would get entertaining...), the entire
test-suite is now executing everything in the fakechroot environment.
- Build needs a whole bunch of utilities there, including file + its
magic database. The exact location of the magic db varies between
systems but file -C lets us basically make a copy of the system magicdb
into the fakechroot env and then we can override the location with MAGIC
- Running builds in fakechroot needs a whole lot of things.. add symlinks
to various system config + dev files to give some trivial packages
a chance to build under fakechroot
- Executing rpmbuild in the fakeroot gets fairly tricky, especially
for the tests that actually compile things. Overriding the dbpath
prevents it from accessing system rpmdb for keyring and build-requires.
- With this patch, the test-suite now passes the smoke-test of
"chmod go-rx /var/lib/rpm" on system rpmdb.
- The idea behind the patch is that a missing release is handled
as "all/any release". Nothing changes for "foo < 1.2" or
"foo > 1.2", it still just compares the version. But "foo = 1.2"
means "everything with version 1.2". Thus, any match against
a package with version "1.2" a any non-empty release must
return true.
- Update test-suite expectations to the new behavior.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Turns out this change does more harm than good, people are actually
relying on this behavior to avoid zillion conditionals in the spec.
We'll want a saner way to conditionally disable/enable packages
but until we have that, revert to the former longstanding behavior.
- This effectively reverts commit d010ec1c90
- Add support for new "OrderWithRequires: foo" spec syntax
which has "if and only if foo is present in transaction, order
the transaction as if this package required foo" semantics.
While it looks, and in some ways is, a soft dependency, this
is not the same as recommends/suggests etc: those have unknown
depsolver policy dependent semantics attached to them, whereas
ordering hints have a clear definition and is only relevant for rpm
itself, depsolvers should not even look at the data.
- This allows packages to express correct ordering for optional
functionality, such as
%post
if [ -x %{_bindir}/register-component ]; then
%{_bindir}/register-component %{name}
fi
If the package containing %{_bindir}/register-component is included
in the same transaction, it makes sense to have it installed before the
package(s) that use it. But as it is fully optional, Requires would
not be appropriate. Using OrderWithRequires allows this to be expressed
without dragging in extraneous dependencies for optional functionality.
- Add some basic infrastructure: point PYTHONPATH to the testing
directory, helper macros to allow use of in-line python in test-suite
- Throw in a couple of simple tests for starters
- This is a bad "API" for verification, it can't be controlled and
causes heavy IO where one would not expect it. Getting rid of it now
before anybody starts relying on it...
- Leaving :fstatus format extension alone however, it's at least harmless
and produces a more predictable output than :vflags extension so it
might be actually useful in scripts.
- poptExecPath() pointing to meaningful place allows removal of these.
- Make test-suite rely on the --initdb exec alias so we catch out
if anything here breaks
- Track posix.fork() and only allow exit() and exec() if the script
has forked. There are other questionable items in posix extensions
too but these are the worst offenders.
- Using Lua registry for tracking forked status might be more Lua-way
option but this'll do for now.
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.
- Avoids having to link /bin/rpm with librpmbuild and everything it
might bring in (eg libmagic) which are not needed for core operation.
- Minimally preserve backwards compatibility with popt exec alias
- Add popt exec aliases to rpmdb for backwards compatibility
- Change test-suite to use 'rpmdb --initdb' instead of 'rpm --initdb'
as popt exec aliases with absolute paths dont play very well
with the test-suite, duh...
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.
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.
- Permits basic file verification with just a headerGet(), with some
caveats: there's no way to control which attributes get verified,
and there's no filtering of mtime differences of shared files. Those
aside, rpm -q --qf "[%{filestates:vflags} %{filenames}\n] <args>" now
performs the same as "rpm -V --nodeps --noscripts <args>"
Panu Matilainen