- Python users are unlikely to have much use for this thing as such,
python has plenty enough native datatypes to not bother with rpm
specialties. The primary reason for adding it is to allow utilizing
a shared string pool for various rpm objects from python side as
well. That'd only require being able to pass the pointer around
for which we wouldn't need a full-blown object, but otoh creating
test-suitet cases in python is nicer than in C so having at least
the base methods available wont hurt...
- Rename the file index argument for rpmfnDI(), rpmfilesDI() and
rpmfilesODI() to ix for consistency with other file index arguments
- Document rpmfilesDI() and rpmfilesODI() and its usage with rpmfilesDN()
and rpmfilesODN()
- rpmfiles API is mostly a copy-paste of rpmfi with index argument
added
- clarify rpmfi.h docs to speak about "file info set iterator",
rpmfiles.h is the "file info set" thing now
- All the public rpmfiFoo() accessors have an indexed rpmfilesFoo()
counterpart, make the rpmfiles-versions public too.
- The noteworty exceptions are rpmfiDecideFate() and rpmfiConfigConflict()
which shouldn't have been public in the first place, and are to be
removed from the API in the next API break. So we're not adding
new rpmfiles-counterparts for functions that are to be removed
from the (public) API. Actually document the issue by deprecating
both rpmfi-functions.
- The iterator types need to be in rpmfiles.h as the iterator
constructor is there (otherwise there'd be a cyclic include
between rpmfiles.h and rpmfi.h, which wont do...)
- 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.
- Nothing outside rpmte.c should be able to muck around with the
file info set associated with the ts element. Except to free
memory, which is the only thing rpmteSetFI() is now being used for.
- This simplifies things a bit as we dont need to worry about the
id storage and the starting location of the next string in advance.
- Also make it clearer the string is copied into the current chunk,
to which pool->offs only points to. Make pool->offs const to
enforce the strings are never written through it.
- Assign newly alloc'ed chunks to pool->chunks, pool->offs just
contains pointers into the chunks. This doesn't change actual
behavior at all, just (IMO) clarifies the code a bit.
- As pointed out by Michael Schroeder in
http://lists.rpm.org/pipermail/rpm-maint/2013-September/003605.html,
the dummy entries used for optimizing rpmstrPoolStrlen() are
problematic in number of ways:
- Walking the id's in a pool is unreliable, and rehashing can cause
bogus empty strings to be added to a pool where they otherwise
do not exist
- rpmstrPoolNumStr() is not accurate when more than one chunk is in use
- Unfortunately this means giving up the rpmstrPoolStrlen() optimization,
for now at least.
- Avoid pool setup + teardown for each and every dependency we create,
and string copy between pools on subsequent rpmdsMerge(). Probably
wont make much of a difference in practise since the number of
dependencies per package isn't *that* big, but wont hurt either
(and who knows what kind of texlive-monsters we get thrown at...)
- The comment about ghosts on build may (or may not) have been accurate
at some point in history but that hasn't been the case in a very, very
long time...
- Encountering hardlinks can affect fsm->postpone value which we
must not modify if it was already set due to file-pre hook failure,
and we can't just break out of the loop on failure as file-post
hook must be called symmetrically, ie even in case of failure.
- Leak introduced in commit 9bf578376d
due to change in init sequence, rpmfnInit() needs to be passed a pool
so we need to ensure one exists before calling it. Previously
pool was allocated/referenced lazily only on packages with files, and
rpmfilesFree() assumed that behavior.
* Write headers while iterating over the files
* Handle hard links within the Iterator
* Remove rpmfiAttachArchive()
* Remove rpmfiArchiveWriteHeader() from the API
* Make CPIOERR_* negative
* Make CPIO_CHECK_ERRNO a value instead of a bit
* Make CPIOERR_HDR_TRAILER -1 as this is end of iterator
* Rename CPIOERR_MISSING_HARDLINK to CPIOERR_MISSING_FILE for clarity
- There's no benefit to using char here, and int is what is generally
used for such (flag-type) arguments.
- As it happens char doesn't even work here as the nodigest argument
passed from fsm is not a simple 0/1 value but result of
(rpmtsFlags(ts) & RPMTRANS_FLAG_NOFILEDIGEST), which when crammed
into a char actually turns into a zero... so this unbreaks
--nofiledigest
- Check for multiple ':' and '-' separators (eg foo >= 1-1-1)
which is not valid. Based on James Antill's patch on rpm-maint
(http://lists.rpm.org/pipermail/rpm-maint/2013-November/003640.html)
but modified to avoid bogus spec line numbers on invalid
autogenerated dependencies.
- rasprintf() is of course an overkill for the simple constant strings
currently here but making it allocated gives us room to be more
detailed. No visible changes here though.
- The low element is never used for anything, the high element
has been used to communicate insertion point from rpmdsFind()
to rpmdsMerge(). Which only needs an additional return value
from find, arrange this with internal helper and axe the
stupid struct members.
- rpmdsMerge() relies on bsearch high element from rpmdsFind(),
hysterically preserving the bsearch helper variables in the struct.
Reduce the number of references to make next step more obvious,
no functional changes.
- Get rid of the crazy tag-tango around rpmfi in genCpioListAndHeader():
pkg->cpioList is an rpmfi with the actual in-package paths, and
on-disk package paths are passed around as a separate array. This
simplifies and sanitizes things a lot... and also finally gets rid
of fi->apath entirely.
- Dependency generation wants on-disk paths, but it can generate those
by prepending buildroot, which actually makes it more obvious what's
going on.
- This also kills %{_noPayloadPrefix} ancient-history compatibility flag.
We could honor it in rpmfiArchiveWriteHeader() if we cared but we're
talking about rpm < 3.0.5 compatibility here ... so we dont.
- Use open() instead of calling file constructor
- Borrow python-six trick of dealing with difference in string types
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Passing all the td's to saveRelocs() doesn't make much sense,
do it on the spot. Now that saveRelocs() simply saves the original
paths, rename accordingly...
- This stuff doesn't belong in rpmfi, rpmte, psm or anywhere else either.
Invent a new dark hole to shove it into...
- No functional changes as such, just shuffling things around.
- Only makes things slightly harder but we'll need this later
- This requires retrieving filenames twice, but this is hardly
a performance-critical place...
Panu Matilainen