Maybe also dtype=9?

https://pagure.io/fork/mikem/koji/commits/pr3714updates#

This should cover all current tag types.

Also kinda wondering if we should also decode in get() for dtype=6, but that would be an api change.

I'm not sure here. But if we do that, dtype=8 need also decoding.

@mikem Is there a reason to not reraise exception in dump/9?

Is there a reason to not reraise exception in dump/9?

The goal of dump is just to report what it finds. Bad content in an rpm header shouldn't be an error, just a fact to report the details about.

But if we do that, dtype=8 need also decoding.

An old comment had me misinterpreting type 9. The difference between type 8 and 9 isn't unicode or not, but internationalization. When rpm reads an i18n entry, it checks RPMTAG_HEADERI18NTABLE and the current locale for translations (unless the HEADERGET_RAW flag is used). That behavior is way too much for this class to bother with, so I think we just emulate the raw behavior (which treats type 8 and 9 essentially the same).

The python bindings from rpmlib itself return all these header types (6, 8, and 9) as strings, and in casual experiments rpmbuild errors if you try to make an rpm with invalid unicode in such fields.

RawHeader was originally written for python2 and didn't have to worry about the distinction. We didn't add any decoding to _getitem in the py3 port, so now we have an established history of returning bytes.

Added some changes here that make the decoding optional and more systematic. Also some other fixes.

This is inflating a bit and it might make sense to combine with my other PR (#3703). Wouldn't hurt to add some unit tests too.

Is #3713 causing us a problem somewhere? If so we could probably just go with your original commit for the sake of getting a fix.

One thing I'm still puzzling about is that all the actual examples of dtype=9 I've seen are count=1 and rpmlib seems to return then as single strings (e.g. summary, description) rather than a list.

I've combined these changes and my updates into #3703

It seems that most of the changes from here were added to #3712 inadvertently. Only the "flake8 fix" commit is left if this PR is rebased (and make flake8 seems fine without it).