On 12/12/2016 06:13 PM, proyvind wrote:
Skimming through your link to suse's patterns, it's hard to easily grasp
it's purpose, while if serving the same purpose, the implementation of
is not only extremely confusing, hard to maintain and extremely
non-standard fashion, rather than implemented in rpm itself in a proper,
intuitively named way for wider adoption.

As the group tag more recently has been made optional, with it's
replacement that's not limiting to single tag value, requiring
standardized set of groups being moved out of rpm, this is really bad
considering cross-compatibility, with functionality tied to distro
specific dependency solver.

The groups tag was never standardized nor correctness enforced, so it is/was truly useless for almost all purposes. Probably seemed like a neat thing back in the nineties with a couple of hundred packages in the entire distro :)


By rather introducing the trivially implementation of MetaTags:, a
proper replacement for group tag is provided in rpm itself where it
should be, while the support of multiple meta tags rather than group,
aids the vendor specific groups that's not standardized across distros,
leaving yet another obstacle for cross-distro packaging compatibility.

I hope this better explains it's purpose, rationale, motivation and
benefits of. :)


I implemented essentially the same thing back in 2008 but with "keywords" as the tag. Never committed it since a free-form string array is likely to end up as a junkyard of typoed cruft - just like group was, only worse.

Sort of related to that: for every reason to include such data in packages themselves, there's a counter-argument. For example, you really, really dont want to end up rebuilding the kernel or LibreOffice or such just to add, remove or typo-fix a keyword/tag. And tags in packages it's unlikely to be useful for, say, distro/spin-composing in the way eg comps is used.

It's just one of those things that seems like a decent idea but coming up with an actual use-case isn't that easy.

        - Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to