On 11/5/19 1:17 PM, Stephen Gallagher wrote: > I'd like to gather a constructive list of the actual use-cases that > you feel Modularity is causing problems for, with the following > stipulations: Any *subjective* problems will be ignored. "I think > writing YAML is harder than writing a spec file" is an example of a > subjective opinion. Similarly, "change inevitably results in some > learning curve" is a basic maxim of innovation and is not in and of > itself an argument not to change. "Modularity requires me to write > both a spec file and a YAML file, thereby increasing the total work" > is an *objective* observation (and a valid one; I'm going to include > it below in my own starter list). If you aren't sure if it's > objective, a useful question is "is it quantitatively measurable?" > (AKA "Can I assign a number to it and see that number increase or > decrease when changing something about the implementation?")
I find the global exclusion of packages built but not shipped in an enabled module baffling and makes it very hard to provide updates/alternatives to those packages. For example: - I installed a RHEL8.0 system and my kickstart requested "koan" to be installed. - koan is provided by the rhn-tools module, and so that got enabled - rhn-tools builds a very old version of koan that comes from the cobbler package. But it doesn't ship cobbler (or cobbler-web). - As a cobbler packager I want to test out the latest version of cobbler built from my COPR - so I enable that and run: # dnf install cobbler Copr repo for cobbler owned by orion 695 B/s | 1.9 kB 00:02 No match for argument: cobbler Error: Unable to find a match WAT? dnf -v is no help, neither is --debugsolver as near as I can tell. Beyond the horrible UX above, this seems so counter to the idea that we are building a platform upon which others can build and extend. In this case I can simply disable the rhn-tools module, but what if I wanted something else from that module? Hopefully the UX is better in Fedora (I haven't tested), but I believe the exclusion property remains. This is also creating challenges for CentOS to re-add missing -devel packages (https://lists.centos.org/pipermail/centos-devel/2019-November/018082.html) though I hear whispers of a fix in the works so I am hopeful... -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
