El jue, 06-04-2017 a las 12:40 +0100, Richard W.M. Jones escribió: > I have a package which needs GNU Privacy Guard (GPG) at runtime. It > can either run gpg (v1) or gpg2, as it uses a subset of the features > supported by both, and the program searches for both binaries. > > The natural way to express this as an RPM dependency would be: > > Requires: (gnupg or gnupg2) > > Unfortunately this is forbidden by the packaging rules: > > https://fedoraproject.org/wiki/Packaging:Guidelines#Rich.2FBoolean_ > dependencies > > (BTW the link in that section is wrong - it should go to: > http://rpm.org/user_doc/boolean_dependencies.html ) > > This admonition was added in: > > https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&di > ff=prev&oldid=441810 > > What's not explained is why, except that it "causes issues with the > package updates process". It seems as if the or-rule above would be > simple enough, so what's the exact problem? > > Rich. Even when we think we have everything in place to support rich deps, we are going to have to tread very carefully. There is likely a bunch of corner cases forgotten. Including potentially anything that tries to read a rpm. we will need to do extensive testing in staging before we can let things loose. To ensure that we can fully support them. I would had to say to people go for it and we find some thing hidden in a corner that will take us a year solid to fix and force everyone to undo the changes. This is a good example of why we can not develop new features in isolation, instead we need to work as a whole. we have plenty to learn from the pain of rich deps and dnf, changing core pieces is hard, and historically we have done a bad job of documenting all the interdependencies, I will put my hand up first as having contributed to the problem. I just want us to make steps to get better going forward. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
