rpm-software-management/libcomps

Feature request: negative arch filtering

AdamWill opened this issue · 0 comments

So, I just wrote a script that looks for pkgreqs in Fedora's comps for packages that don't actually exist. And made it work by arch.

Turns out there are quite a few packages which exist on all arches but one, e.g.:

Package podman not found for arches i686
Package buildah not found for arches i686
Package isdn4k-utils not found for arches s390x
Package efax not found for arches s390x
Package statserial not found for arches s390x
Package 389-ds-base not found for arches i686
Package 389-dsgw not found for arches i686
Package pki-ca not found for arches s390x
Package pki-console not found for arches s390x
Package pki-kra not found for arches s390x
Package pki-ocsp not found for arches s390x
Package pki-javadoc not found for arches s390x
Package pki-tks not found for arches s390x
Package pki-tps not found for arches s390x

so, it might be nice to adjust their comps entries to say 'include this package in the group on all arches except this one' (or two, even). But we can't do that. We can only do 'positive' lists of arches. This is fine for cases like bootloader packages which we know only exist on one or two arches, but it's kinda bad for packages where we know they'll exist on 'any arch EXCEPT this one or two', because any time we add a new arch, we'd have to adjust the entry to include that new arch...it's also just not very clear from an entry like this:

<packagereq arch="aarch64,armhfp,i686,ppc64,ppc64le,x86_64" type="mandatory">grub2-tools-extra</packagereq>

that it really means 'this package exists on all arches except s390x'. You have to really know what arches actually exist to look at that line and figure out its real intent.