After some consideration, we'll consider this a request to enhance the Python
bindings API to allow selectively dealing with extension vs raw header data
like the C API can. Besides letting the tag die of old age, that's the only
concrete thing we can do without breaking some usecase or the
This remains a design bug, basically, and should eventually be addressed one
way or the other.
One of the practical, not-incompatible things we could do is provide a way for
Python to access the raw header data, whereas it currently is hardwired to
always use extensions.
--
Reply to this
It's not an issue of format, it's a tag number issue and tag numbers are
forever. The best chance is probably to let the whole tag die (replace by MIME
types)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Can we at least fix this in RPMv6?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1563#issuecomment-790441286___
Rpm-maint
Then we'd have to do the same for any number of other tags as well...
Header manipulation from Python is little more than a toy ATM.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yup, this unfortunate collision is actually even documented now :sweat_smile:
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/tags.md
There's no good way to fix the collision between the fundamental tag and the
extension, because one way or the other, it'd break one thing
The following assignment doesn't work due to type incompatibility:
```
new_hdr[rpm.RPMTAG_FILECLASS] = old_hdr[rpm.RPMTAG_FILECLASS]
```
rpmtag.h claims that it is a list of integers:
```
RPMTAG_FILECLASS= 1141, /* i[] */
```
but the content are strings:
$ rpm -q bash --qf
