| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
a fast way to list all installed packages are
check if some package is installed. This is a hack.
|
|
|
|
- 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.
|
|
|
|
- Additionally clean up the logic a bit and dont bother building
any lua-related bits if disabled
|
|
- It contains piles of buffer overflow etc material and AFAIK this
has been unused for its entire lifespan of > 10 years, fixing
an unused piece of code seems like a waste of time. If somebody
shows interest later on it can be resurrected, but in the meanwhile...
|
|
- canon arch & color stuff is now calculated per each known arch in
installplatform, and just a single place where arch name mangling
is done
|
|
|
|
Implement link reaction with less copied code
|
|
- 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.
|
|
- Dealing with the inevitable fallout and popt-foo needs more time
to handle, revert to the rpm 4.6-4.8 setup where rpmquery and rpmverify
are just symlinks to /bin/rpm, allowing especially query aliases
to work. Releasing an intermediate version where 'rpmquery --requires'
and the like dont work would do nothing but hurt the future intention
of splitting these things up for real.
- This effectively reverts commit 26125015e4321765582dce0b76f83530e7604d4e
|
|
- It's a bad name for something that can also erase packages, leave
the install/upgrade/erase modes for /bin/rpm instead.
|
|
|
|
|
|
- Installing/erasing packages, querying and verifying require different
amount of privileges on the system. Having separate binaries for
these functionalities permits limiting the capabilities through
SELinux and other similar security mechanisms: for example quering
needs much less privileges than installing.
- For now, leaving /bin/rpm to be the Swiss Army knife it
always was: capable of install/erase, query and verify. Eventually
it should be turned into just a dumb wrapper which just execs
the per-functionality binaries, but leaving that for later stage,
as popt exec/aliasing doesn't quite seem to up to par with the task.
Having the separate binaries available at least makes it possible
for callers to specify the amount of privileges they need.
|
|
- 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
|
|
- For now this is really just to allow building statically while
hacking, for "real world" use this has implications on collections
support etc which is not handled by this patch.
|
|
- Conditionalize the python subdir on toplevel make instead of
python subdir makefile.
|
|
- 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).
|
|
- 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...
|
|
- rpmdb maintenance only requires privileges on the rpmdb directory,
not elsewhere on the system. Splitting to separate tool allows
finer grained SELinux policies and makes adding new db-specific
switches saner.
|
|
- Add popt exec aliases to rpmkeys for backwards compatibility
|
|
- Keyring operations (adding/viewing/removing keys and verifying
packages against a given keyring) are different from main rpm operations
in that they only need access to the rpm keyring, and no write access
anywhere else in the system. At the moment the rpm keyring happens
to be the rpmdb but that's just an implementation detail that is
likely to change sooner or later. Besides paving way to separating
the rpm keyring from the rpmdb, splitting this to a small, separate
utility allows limiting its required access from SELinux POV etc.
- For now, this only implements what's already in rpm: --import and
--checksig, remaining operations like listing and manipulating
keyring contents is left as an exercise for another day...
|
|
- Add popt exec aliases to rpmsign for backwards compatibility (dejavu...)
|
|
- Signing (and deleting) are different from everything else in rpm
in that it needs very little of rpm's facilities. For example access
to the rpmdb is not needed at all. Splitting this to a separate,
small utility allows various possibilities, like severely limiting
its access from SELinux POV, control of signature generation with
cli arguments (the main rpm executable is already overcrowded with
options). It's also the first step to allow reasonably splitting
rpm signing to a separate package; not everybody needs to sign
packages, yet signing support needs to drag in GPG and whatnot.
- Reimplement / refactor various librpm signature generation helpers
into somewhat saner internal versions.
|
|
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.
|
|
|
|
|
|
|
|
|
|
- Make a copy of the entire rpmqv.c source to rpmbuild.c and switch
make to use the new copy. No functional changes. Making a copy first
means we get much easier to follow patch-series on the changes
that will follow.
|
|
This patch adds a generic plugin, exec.so, that should be sufficient for the
majority of Collection actions. After all packages in a Collection have been
installed/removed, this plugin executes the arguments by calling system(3),
allowing for a very generic and powerful method to perform many actions.
This also adds two sample macros as examples of the format, using the exec.so
plugin.
|
|
- rpmps is just something that stores rpm problems, problems themselves
are individual and opaque "objects", deserving their own module
|
|
- 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
|
|
|
|
- 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
|
|
- patch from Michal Čihař
|
|
- xml format dump gives an output that can actually be further processed
|
|
|
|
- rpmal is hardly useful outside rpm itself, avoid exporting stuff
unnecessarily
|
|
|
|
- this allows popt aliases to be reliably available in tests
- why do we have the popt initialization done twice?
|
|
- we're just mangling varprefix to localstatedir anyway, might as well
just avoid that little extra trouble...
|
|
|
|
|
|
- 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...
|
|
- nobody has used the solvedb for anything in years
- the mechanism + rpmcache are horribly broken on multilib
- solvedb is way too heavyweight to be really usable as a general mechanism
- solver callback hook left in place as that could in theory be usable still
- we need something better to replace this all, getting rid of it now
so we're not stuck with the API forever
|
|
|
