It's been deprecated and hidden behind compat defines for eight
years now, more than enough time for folks to port their stuff
to new APIs. If they ain't done by now ... well its time now.
- Preparation for making the indexed rpmfiles API public, API users
are not affected as rpmfiles.h is included from rpmfi.h now. rpmfi.h
is for the iterator part only.
- The pool stores "arbitrary" number of strings in a space-efficient
manner, with near constant (hashed) string -> id lookup/store and
constant time id -> string and id -> string length lookups.
- Credits for the idea go to the Suse developers working on libsolv,
the basic concept is directly lifted from there but details
differ due to using rpm's own hash table implementation etc.
Another minor difference is using size_t for offsets to permit over
4GB total data size on 64bit systems, the total number of id's in
the pool is limited to uint32 max however (like in libsolv).
- Any (re)implementation bugs by yours truly, this is almost certainly
going to need further tuning and tweaking, API and otherwise.
- Base64 is present in headers and all, it's only reasonable that
our API users have access to this functionality without having
to link to other libraries. Even if we didn't want to carry the
implementation forever in our codebase, we should provide a wrapping
for this (much like the other crypto stuff) for the reason stated above.
- A bigger issue is that our dirty little (badly hidden) secret was using
non-namespaced function names, clashing with at least beecrypt. And we
couldn't have made these internal-only symbols even on platforms that
support it, because they are used all over the place outside rpmio.
So... rename the b64 functions to rpmLikeNamingStyle and make 'em public.
No functional changes, just trivial renaming despite touching numerous
places.
- We'll probably want to make some changes to the plugin type system
before considered "ready", the current plugin slots are limited
to 32 and Meego folks apparently want to use a largish number
of slots. So we might want something like separate plugin type
(collection, security... etc) and then have 32 slots per each type.
Making this private for now to avoid having to potentially break
the API shortly after introduction.
- For a library with just one public function this might seem like
a huge overkill but it permits cleanly separating dependencies:
nothing but package signing requires GnuPG. This lets the signing
support be stuffed into a separate package, avoiding having to
drag gpg in on every installation (signing isn't something everybody
does) and without having potentially broken interfaces in the API,
essentially solving RhBug:624585.
It also liberates signing to use libraries that might be off-limits
for the core rpm, such as perhaps in the future doing signing
by ourselves with the help of something like gpgme (which requires
far too many things to drag into core rpm).
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.
- build-time generated rpmints.h causes issues with distcheck and is
not really worth the trouble
- we have all sorts of legacy junk to deal with, sticking them all into
rpmints.h would be just wrong...
- not possible to do reliably within rpm
- effort is better wasted on investigating fs-level snapshots, which
is way beyond rpm scope except for hooks to interact with the snapshot
mechanism to communicate beginning/end of transaction and such
- atm consists of portability wrappers to various gcc extensions like
__attribute__() to provide additional warnings and checks
- copied from glib to avoid an extra build dependency just for the silly
macros, renamed to avoid namespace clashing
Panu Matilainen