- Unfortunately patch'es idea of "interesting" output is not ideal for
our purposes: "patching foo.c" is of little value, but hunks with
offsets and fuzz can be important and there's no switch to patch
to get exactly what we want. So let it be chatty... build logs are,
anyway.
- Defaults should be for the common case with disablers for those who want
to do something special, and typically if you have patches you also
want to apply them. Change it while we still can: eliminate -A option to
%autosetup and apply all patches unless -N option is used.
- These are both "appears to have roughly the intended effect" level
tested, but I'm not really familiar with either bzr or quilt so
any further refinements need to come from people actually familiar
with these tools.
- This adds two main macros (+ bunch of helpers) to automate the
common case tasks in %prep:
1) %autopatch which automatically applies all patches from a spec
2) %autosetup which (optionally) takes care of it all, and (also
optionally) sets up a git/hg repository of the unpacked source +
applied patches as it goes.
- This should be considered a starting point only, there are various
things to improve. Eg we'd like to be able to make backups
with plain patch (based on patch number maybe) and at least with git,
we'd like to be able be (optionally) use 'git am' patching style
to preserve original authors + commit messages etc.
- A noteworthy point here is that as these are fully implemented as
macros, they are compatible with several older rpm versions as well.
- Now that this is relatively sanely doable... make %license with
non-absolute paths behave similarly to %doc, only installing to a
different directory (%_licensedir) and with different flags:
licenses are not generic documentation and should not be skipped
on installation even if --nodocs is used. The common practise of
stuffing licenses into %doc actually violates various licenses
which require the license text to always accompany the software.
- While ticket #116 suggests various schemes to reduce disk usage,
adding some very special logic to installation code just to deal
with these doesn't seem justifiable, given how small the licenses
generally are. However with licenses now in their own directory
structure (/usr/share/licenses by default), running hardlink on
them is trivial for cases where disk space is tight
(live images, embedded systems etc)
Teach %prep and %uncompress how to handle 7zip tarballs, with
the mingw toolchain landing in fedora, this may be useful when
crossbuilding Windows sources compressed using 7zip (CxImage is
one such project).
autotools dependency tracking isn't generally useful in rpm builds;
disabling it results in cleaner build logs and possibly slight build
speedups.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- We need to grow some digest (and why not external signature as well)
validation mechanism before we can let rpmbuild download + execute
arbitrary content from the internet, at least by default.
- A larger cache is beneficial in various scenarios, but triggers
horrible worst-case performance under memory pressure (or so my
current theory goes, there might be other factors too). The
worst-case degration is orders of magnitude bigger than the best-case
improvements from the larger cache and for many use-cases doesn't
make a whole lot difference. We could/should tune the cache with
priorizing indexes and all, and perhaps dynamically select the
cache size but for now, the 1Mb cache size is known to "just work".
- While it would be perfectly reasonable to perform signature
checking during db rebuild, this is problematic as long as our
keys live in the same database we're rebuilding: the environment
might be paniced, the indexes required for key lookups might be
corrupt or non-existent etc - one would assume there's a reason for
the db is getting rebuilt in the first place. When signature checking
is enabled, we're forced to generate missing indexes on the potentially
borked database we're just about to rebuild, which might not go very
well, and since they keyring loading has no clue its getting called
from middle of db rebuild it'll try to use a shared environment
which might be broken ... etc.
- Fixing broken permissions in sources isn't exactly platform/vendor
specific in nature (at least Suse adds this this to their own "platform"
separately, kinda proving the point)
- Kick out the remaining unused RH-pecific platform.in section
- The former defaults come from nearly a decade ago, things have
changed a bit since then... Even BDB's own default cache size is
much larger (8MB) now than what we've been setting.
- Using 64MB cache improves cache hit rate (and performance) massively.
Last-gasp default to roughly BDB's own current defaults, higher
settings in the default macro setup.
- Changing db_api to db_ver to force breakage on anything using the
value, db_ver containing the BDB major version just to put something
in the error messages where the dbapi version used to be.
- Add a crude flags system to allow selectively enabling the extra
grouping during ordering: currently only sepolicy collection needs
this, and its very harmful when applied to more regular collections
as it creates truly gigantic dependency loops that rpm has no chance
of sorting out sanely.
- The different access methods have different capabilities and are not
interchangeable in all situations. Currently we can use either
hash and btree but this might not be always the case for all indexes.
- We'll eventually want to force-switch the index types to our liking,
but for now follow these simple rules:
1) For existing databases, we accept both btree and hash
2) For newly created databases, the main Packages database remains
a hash, all indexes are btrees.
- Rip out nearly all the rest of the remaining macro configuration.
- Rpm knows how to handle db rebuilds by itself, no need to expose
these bits to configuration.
- Also rip out a pile of other leftover "documentation" about BDB
internal switches.
- Plugins are by their very nature arch specific, while /usr/lib/rpm
is a hodgepodge of all sorts of ... stuff, most of which is
arch-independent and all. Use %{_libdir}/rpm-plugins to cleanly
differentiate 32 vs 64bit plugin paths
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 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.
- We always create an environment. If we dont have permissions to create
or join a shared environment, we use a private environment. Instead
of trying to figure out what to do beforehand, retry dbenv->open()
with different flags to see if it succeeds. This eliminates some
potential races when others might create/remove the environment
while we're pondering about appropriate flags.
- Lose the "create" bdb config option, this is something we always
want to decide internally.
- Remove "force" bdb config option, DB_FORCE is dbenv->remove() option
and its value clashes with DB_CREATE...
- lose the hysterical dbi_use_env condition and usedbenv option
this is always enabled
- ensure mpool is always initialized, lose the config option (this
is a mandatory BDB subsystem, not a bleeping configurable)
- let pagesize be what it is even when no configuration is present
- avoid overriding dbi_mmapsize and dbi_cachesize if set in the configuratio
- these are all per-environment, not per-dbi settings but for now...
- we never want DB_CREATE to cause failure - let BDB create the
db if it needs to, otherwise DB_CREATE doesn't do anything
- rdonly is decided elsewhere, not in bleeping configuration
- The last temporary db was Depends which is now replaced with an
in-memory hash, and the temporary dbs were troublesome with
chroot operations anyway, good riddance
- We dont grow new indexes every other day, and especially this
is not activity that users need to be able to do
- Gets rid of the hysterical initialization and million can't happen
NULL-checks
- 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
- 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.
- 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).
- 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
Panu Matilainen