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
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
a separate attribute but the usefulness of it would need to be
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
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.