- Hasty push-finger syndrom, while its not exactly plain wrong to
do things this way, it doesn't really make sense for these types
either. Python's own file object permits reinitialization though,
so leaving rpm.fd() the way it is now.
- This reverts the following commits:
d056df28c33f77c3146d7214b2e0a2dc50fb2863
- Creating ('foo', '>=', '1.2') dependency is much nicer than
or'ing rpm.RPMSENSE_FOO for flags. Allow (but validate) the string
usage, ints get passed as is.
- rpmdsNew() returns NULL if the requested dependency type doesn't
exist in the header. The C-side API can handle NULL to all rpmds
"methods" and this is how librpm deals with non-existent sets rather
than waste memory on for empty ds structures. However the python side
wasn't expecting NULL for legal requests (but not setting error either)
and thus blowing up with SystemError exception.
- Raise TypeError on illegal arguments to rpm.ds constructor, and present
non-existent dependency sets as empty rpm.ds objects to python. This
lets python callers use iteration over ds items regardless of whether
the dependency actually exists or not. The alternative of returning
None (or raising exceptions) would break existing code for no
particularly good reason.
- Buildtime was never part of rpm version comparison nor should it be,
on rpm level the only sensible differentiator between two identical
dependencies is the dependency color if any. Other than that, random()
just as "appropriate" as build time.
- both comparison types are highly ambiguous, eg what on earth does
"foo provides bar = 1" < "bar requires foo > 2" mean?
- if straight ds1.evr vs ds2.evr comparison is needed, we'll be better
off supporting that through rpm.versionCompare() which has clear semantics
- avoids another Python 3 incompatibility too
- HAVE_RICHCOMPARE is included in Py_TPFLAGS_DEFAULT since at least
Python 2.3 which is as far back as we care, no need to explicitly
set it. Eliminating the unnecessary flag removes another Python 3
compatibility issue as the flag is gone there.
The layout of PyVarObject changed between python 2 and python 3, and this leads
to the existing code for all of the various PyTypeObject initializers failing to
compile with python 3
Change the way we initialize these structs to use PyVarObject_HEAD_INIT directly,
rather than merely PyObject_HEAD_INIT, so that it compiles cleanly with both major
versions of Python
Python 2's various object structs use macros to implement common fields at the top of each
struct.
Python 3's objects instead embed a PyObject struct as the first member within the more refined
object structs.
Use the Py_TYPE() macro when accessing ob_type in order to encapsulate this difference.
- either it takes a header + tag, or (name, flags, version) tuple + tag
to generate a single dep
- push rpm.dsSingle() compatibility out to python side
- hdr.dsFromHeader() and hdr.dsOfHeader() no longer need to be in rpmds-py.c
- use PyErr_WarnEx() for better control and leave the tracking up to python
- use PendingDeprecationWarning for now
- document the replacing functionality in the deprecation messages
- make hdr.sprintf() just an alias to hdr.format() without deprecating,
at least for now it'd be only a gratuitous incompatible change on python side
- these violate the intended use of tp_print, python docs state
"A type should never implement tp_print in a way that produces
different output than tp_repr or tp_str would."
- raise exception in tagNumFromPyObject(), not in 12 different callers
- check against RPMTAG_NOT_FOUND consistently instead of -1 and whatnot
- unknown tags are value, not key or type errors
Panu Matilainen