Le mardi 23 juin 2020 à 20:31 +0200, clime a écrit : > Or we can bring the notion of > the namespaces into rpm itself (that's where my suggestion of > "Stream" > rpm attribute comes from but it could also be called just > "Namespace"). But then there is the argument: "Why not just put the > namespace into rpm name itself?" I mean...I wouldn't mind having it > as > a separate attribute but the usefulness of it would need to be > discussed. The namespacing information will eventually need to be pushed to the package level because it’s not possible to do cool stuff with things that do not exist at the atomic component level. However rpm (the tool that creates the deployment format) sucks loads for managing variables/attributes at scale. RPM tags are completely inadequate for the level of variabilisation the distribution needs today (and getting more inadequate BTW — there are new tag constrains in rpm 4.15+ that did not exist before). That’s why we have to shove level after level of unrelated complexity in a single Release tag, that’s the whole changelog/autobumping discussion (I have other examples but they would not speak to the general audience on this list). You can bypass a lot of rpm format limitations by giving up on Tag uses altogether, using rpm macros/variables instead of tags in the spec file, and exposing the new metadata in foo() provides, but you will still hit the brick wall of handling all those new variables at the spec level. IMHO Modularity functional objectives were good, implementation was bad, first by confusing a build framework with a deployment stream format, and second, by not investing in the actual tool that creates our deployment format, to make it scale to the levels of complexity modularity requires at the component creation stage. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
