Age | Commit message (Collapse) | Author | Files | Lines |
|
- while the "really public" API of librpmio has only been enhanced,
librpm and librpmbuild use some supposedly internal bits which *have*
changed considerably, so just to prevent anybody thinking they can
combine librpmio from rpm 4.7 and librpm from this...
- librpmbuild hasn't seen much real change but some (unfortunately)
exposed struct members have changed so...
- librpm is mostly compatible but as rpmal has become internal API,
we need to bump (annoyingly, as nothing actually uses rpmal ... sigh)
|
|
|
|
- need to figure out saner semantics & stuff...
|
|
- this is how python built-in dictionary works, be consistent with that
- also avoids having to decide what to do with rpm.td type right now...
|
|
|
|
- Python >= 2.6 is known to work, 2.5 might be possible with __future__
imports but until somebody tests it...
|
|
- on selinux enabled systems, 'ls -l' mode string is longer than
expected here, just trim the ls output to our expected length
|
|
- we currently only support creating regular files for %ghosts which
dont exist in the buildroot, but for files that do exist in the buildroot
there's no reason to place such limits (eg its perfectly ok to have
symlinks marked as %ghosts)
|
|
|
|
- these scripts aren't processed for translation and unlikely to ever be...
- fixes the remaining complaint from ticket #62
|
|
- also eliminates one more "bashism" complaint of ticket #62
|
|
- fixes one of the bashisms in ticket #62
|
|
|
|
- hdr.fiFromHeader() is just a deprecated backwards compatibility dummy
and doesn't need to pass anything as there were no meaningful
parameters in older versions
|
|
- Generally only executable files are critical for dependency extraction,
whereas oddball application data files can cause unnecessary build
failure due to libmagic misdetections etc, so just let non-executables
pass with a warning and mark them as unknown data
|
|
- instead of doing stuff by "hand" and getting it wrong, let autoreconf
worry about getting it right (if nothing else, we can then blame
autoreconf instead of ourselves ;)
|
|
- Execve() failure wasn't returning an error code, causing rpm to
think the password was ok when we couldn't even try verifying
- Stricter return code checking from the password checking child:
the password can only be ok if the child exits with WIFEXITED() *and*
WIFEXITCODE() of 0. Also WIFEXITCODE() should only be called if
WIFEXITED() returns true.
|
|
- parsing subkeys ends up overwriting data in the main key, causing
bogus signature checking failures
- this is the final missing piece of RhBug:436812, short of adding
proper support for subkeys (maybe someday...)
|
|
|
|
|
|
- no proper i18n string support yet, just the basic types
- basic data type validation only, no overflow checking for integer types
- for lists, validate all items before trying to insert anything
- duplicate tag creation not permitted
- appending not permitted, only assignment (and deletion already)
- there are probably bugs...
- watch out for librpm bugs when passed incomplete headers, ugh
|
|
- its not that clear that exporting the td type is really useful
(certainly not in its current form), avoid exporting an interface we
might not want to support
|
|
|
|
- this is supposed to automatically generated on update-po time from
toplevel rpmpopt file and merged into rpm.pot but has been broken for
a long long time and also the $ translation marking has been deprecated
for security reasons
|
|
- Python 3 removed has_key() from dictionaries, as the 'in' way is the
way of the future support that from the start (has_key() is not in
any released rpm version so its safe to remove)
|
|
- this is available through tag extension now, no point having a
separate method for it
|
|
|
|
- simply make readonly filesystems appear as full, preventing install
early instead of failing with cpio errors in middle of transaction
|
|
|
|
- patch from Michal Čihař
|
|
- return RPMTAG_EPOCH but convert non-existent epoch to 0, as rpm internals
treat it
|
|
- permits python to access parsed headers from spec files
- ticket #14, RhBug:462726
|
|
- needed for generating header objects from other extension modules &
might be handy in some other cases too
- patently type-unsafe but as long as python doesn't provide a better
way, not really our headache
|
|
- its our own private data structure we're accessing here, no need
for extra wrappers and nothing outside spec-py.c needs this
|
|
- incompatible, but nobody is really using the spec bindings for
anything as there's been very little you've been able do with them
- having the stuff accessible as getseters means we dont need 50 different
fooSet() methods if/when we permit modifying these from python
|
|
- spec without sources is perfectly valid, just return an empty list
instead of invalid NULL return without exception set and simplify
|
|
- prep, build etc missing from spec are not errors
- instead of returning NULLs (with no exception set!), just return None
for anything that doesn't exist
- dont bother with NULL checks, if s->spec is NULL then something else
has screwed up big time
|
|
|
|
|
|
|
|
- since the function takes no arguments, declare it as such...
|
|
|
|
- rpm.ps object only supports iteration and subscript (with wonderfully
wacko semantics), returning a regular list serves us better
- rip the now useless rpm.ps object type
|
|
|
|
- The code to insert new problems has been using invalid conversion code
causing crashes since 2004 and nobody noticed, safe to say this is an
unused interface. Additionally the method argument flags were wrong, it
was declared as METH_VARARGS but actually expected METH_O semantics. RIP.
|
|
- worst case behavior for uncached dependency lookups can be disastrous,
eg > 35s vs < 1s on my laptop for trying to remove /bin/sh provider
- we only bother caching rpmdb lookups, the other cases plenty fast already
- using in-memory cache avoids nasty in vs out of chroot issues with
temporary db files, which otherwise were about as fast
|
|
|
|
|
|
|
|
- we dont require exact int32 etc types, any numeric type works
|