Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[proyvind]

I never really entirely understood what you meant by key:value, could you 
provide an example? :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-305873269___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[Florian Festi]

Closed #107.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#event-976010362___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[Florian Festi]

As long as high end tools cannot be sure that the data they are looking at are 
actually the ones they are interested in but some random, similar looking data 
added for a completely different purpose, this is of no use.  Closing.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-282288042___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[proyvind]

2017-01-26 15:28 GMT+01:00 Florian Festi :

> While I have some sympathy for the idea as such I think just putting
> random stuff in a tags is a bad idea. We should at least force some
> key:value structure. This way someone parsing the tags has a fair chance of
> filtering out the entries of interest without other data littering the
> results.
>
Hm, what do you mean?
The idea isn't for filtering out unwanted entries from appearing in the
tag, but rather for other high end tools to do so.
If concerned about entries of no interest appearing, that's something left
to the tool to rather have whitelists for what tools deemed as interesting
in such a case.

If some packager has added some keyword/meta tag not approved per
distro-policy, then there could be good reasons for it (ie. cross distro
compatible specs), which the package maintainer should be entrusted to
decide, not the release engineer, which I assume is in control of the
fedora comps repository? As the repository only was available through ssh,
I wasn't able to clone it, but I saw 35 forks() for this package,
that's a rather fucked up kind of bottleneck if there's 35 active forks
with changes in queue to be pushed to the upstream one.
And the fact that it's behind some ssh only git repos, doesn't really help
drive community participation or adoption of by other distros if they'd
like adopting the comps stuff..

 While having key names does not provide guarantee if chosen decentralized
> they lower the risk significantly.only vag
>
Yes, distributing the collective efforts onto package maintainers are much
more sane than removing rather than replacing group tag in packages.

I only vaguely remember from looking at the comps repo a little while ago,
although after making some false assumptions of when posting about it
earlier :p , but I remember there being some icon stuff there as well,
although not the details, would it be considered herecy or perverse to
revive the icon tag for such a purpose, moving this collective
responsibilty into the hands of packagers as well? ;)


PS: The over-eager use of acls for git repos as seen in Fedora, with such
as the example illusterated above is extremely counter-productive and by
taking away community's freedom to easily participating in making changes
directly to all package repositories and various software repositories, you
only create bottlenecks and stunt active community participation in all
aspects of the distribution..

For Mandriva Linux cooker project, the more we opened up, the less of past
control freaks concerns turned out to be of great concern and we ended up
only operating with some rarely use blacklists for a very few individuals
for brief periods, even if given the possibility to commit to repositories
of critical packages, people rarely overstepped boundaries nor dared making
crap changes to stuff they didn't grasp, but could still make packaging
policy related changes etc. to packages, making it a less bureacratic
process of evolving packaging policies and enforce them rapidly etc..

Considering that mandriva linux cooker always only had a mere fragment of
contributors to compare with fedora & debian, nor as many people employed
to work on distro compared to debian/ubuntu|canonical & fedora/redhat, it
still managed to stay just as well maintained (packaging wise, far more
well maintained) than fedora & debian and competive throughout it's
commercial lifetime...
This only made possible by fully empowering the community..

A friendly advice from a veteran of the extint Mandriva SA and the former
Mandriva Linux project... :)

--
Regards,
Per Øyvind


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-275594389___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[Florian Festi]

While I have some sympathy for the idea as such I think just putting random 
stuff in a tags is a bad idea. We should at least force some key:value 
structure. This way someone parsing the tags has a fair chance of filtering out 
the entries of interest without other data littering the results.
While having key names does not provide guarantee if chosen decentralized they 
lower the risk significantly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-275400854___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[Michael Schroeder]

About suse patterns: in the old days(tm), they were pretty similar to comps. 
Nowadays they are just rpm packages with standard dependencies. You shouldn't 
try to judge them by looking at that messy spec file.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-266706277___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[Panu Matilainen]

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

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[Igor Gnatenko]

@proyvind @proyvind, I still didn't got use-case for this. Can you show some 
example?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-266473326___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[proyvind]

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.

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. :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-266472856___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[ニール・ゴンパ]

I'm a bit confused. What exactly are MetaTags supposed to do? You mention 
comps, are these supposed to be more like [SUSE's 
patterns](https://build.opensuse.org/package/view_file/system:install:head/patterns-openSUSE/patterns-openSUSE.spec?expand=1)?

I can't quite tell what this is supposed to do...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107#issuecomment-266012048___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[proyvind]

@proyvind pushed 1 commit.

cfe0869  MetaTags: should be translatable


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107/files/8d0a541248e136b1ebcdec93ae4a2d5b9924882d..cfe0869f08b5d0248c4b19e4da29a0eddda6561e
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[proyvind]

@proyvind pushed 1 commit.

8d0a541  update tests with METATAGS added to queryformat test


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107/files/7b838c4eb22c5df3b9a0c308cbe311d8764118c0..8d0a541248e136b1ebcdec93ae4a2d5b9924882d
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Metatags (#107)

[proyvind]

Maintenance of multiple meta tags for packages outside of packages, replacing 
optional group tag isn't ideal wrt. package maintenance scaling..

In stead a MetaTags: tag has been added, accepting multiple tag words.

This seems like a far more ideal solution than what's currently implemented 
with comps groups in dnf, while remaining independent of package solver.
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/107

-- Commit Summary --

  * make sure not to dereference NULL pointer
  * handle new MetaTags: tag

-- File Changes --

M build/parsePreamble.c (15)
M build/parseSpec.c (1)
M lib/rpmtag.h (1)
M lib/transaction.c (3)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/107.patch
https://github.com/rpm-software-management/rpm/pull/107.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint