> This is a dangerous argument, as by this logic we're required to accept
> anything at all that distros come up with.
I am very much aware of this. But considering this is how we were told to
implement this when we started this, I'm a little frustrated now that the
approach isn't good enough anymore...
> Oh, and I'm inclined to agree with @berolinux, provided (and required)
> capabilities would probably be the more flexible route of looking at this all.
Sure, but that _still_ doesn't help with architecture property for things like
`%ifarch`/`%ifnarch` and other similar things. Ideally, we'd have virtual
dependencies for all kinds of hardware things, so that we could do fancy things
like kernel modules supplement hardware and auto-install, automatic proposals
for enhanced packages when CPU has certain instructions, etc.
--
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/pull/1035#issuecomment-588269451
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
