RFC GLEP 1005: Package Tags

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

RFC GLEP 1005: Package Tags

Alec Warner-2
https://wiki.gentoo.org/wiki/Package_Tags

Object or forever hold your peace.

Or argue for 100 posts, either way.

-A
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Alec Warner:
> https://wiki.gentoo.org/wiki/Package_Tags
>
> Object or forever hold your peace.
>
> Or argue for 100 posts, either way.
>
> -A
>

Sounds good, but how do we get consistency in there? I mean... this
only works if we have some sort of consensus about tag names, at least
more common ones.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTLiE2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgxL0QALkNpQpAELADbq/Bz9G8ehmB
bFgJPaDWe/SfnC6VV2zKaIgpTNj6Fa/801sUueXLxVY6AsLpuGt0MJf1Hq8O7pOD
p5MT0zwLfxAuOkFiKDxXcSaGfoV3fRV13PbXv+nSsmBhlek902qMK+a7+nXwxZYx
WtF5PGlIX8JJDvaC6wqdUV0MjSqPrTp1dKOREn6kiBWVRfXcKshFcdpcH74jyzHD
XkT5m9m73FdqJD0Qtje0Ga5iXRKk/zEDQovOAnpbykpmQHRLXGXVPW9s/gm2zqRS
evzYlI5lkSnLrAjSDuoM1t9MLXxb1CtyRKeCjWg5weXL+7YXSe65lqASGa4i27zf
GrydcbRMUERGrcQrDf0Fsee1OepYsPNZ35KxU+yACT0gix5v8kAxheqvgSWRamjw
irwumzpnKV/Xc6vlsy159JwaQqXRcQXK+x+PWQyDe1FESZ+HrpC9NSjzY3L05SpY
rYgd11uQtL+I6RN90pRNYOfBDJ0zDsFw0ZUMe5+nTfL87dgkUN35E014ATQ4dxUF
Y7ZUT7er+Qc40tXNBYeOen2RdpiCKCNy+melsK1qIuh5gIvnTqKhbiw5GSGM/efK
jzr/4WHO1Qm0v0CAN2rR15cYnsvilaIrkSJk0PClqpB85jiwUBjwuz4SNDuded/l
XRcaP6ToJDevR+s55Pom
=PocK
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Ciaran McCreesh-4
In reply to this post by Alec Warner-2
On Sat, 22 Mar 2014 15:33:27 -0700
Alec Warner <[hidden email]> wrote:
> https://wiki.gentoo.org/wiki/Package_Tags

And do what with them? Right now this is a solution without a problem.

--
Ciaran McCreesh

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Rich Freeman
In reply to this post by hasufell
On Sat, Mar 22, 2014 at 7:48 PM, hasufell <[hidden email]> wrote:
>> https://wiki.gentoo.org/wiki/Package_Tags
> Sounds good, but how do we get consistency in there? I mean... this
> only works if we have some sort of consensus about tag names, at least
> more common ones.

The alternative to consistency/etc is crowdsourcing, but there is no
way to get that in metadata.xml (unless you allow it to be edited by
some more accessible service).

The whole build-it-and-they-will-come approach tends to work better if
you're doing crowdsourcing.  As it stands this is more of a top-down
approach, and that usually works better if the use scenarios are
understood in advance.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

hasufell
In reply to this post by Ciaran McCreesh-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ciaran McCreesh:
> On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner <[hidden email]>
> wrote:
>> https://wiki.gentoo.org/wiki/Package_Tags
>
> And do what with them? Right now this is a solution without a
> problem.
>

Finding packages. Descriptions are not consistent, categories too generic.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTLiT4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAglPcP/1KG91ZUg8h0EXB8WsAAfNjd
ESXBQ0nA6MdojIMfQjdBrQAj7l1QHQU10mwCn3arvBzg2rG09i89lCe9cy5cf+MC
dl5Vqw6ukvnCxVqQYrucgcBFf2GLMEvmg8VyML0elbklKn+z2gzBxiUtZNUON3mg
KrSi29DbTA2mZHjgQNc2jK9+B4i4Svv+U0VK2eNkzsDM+PI6yCBjIWq13rkKQZRX
nIkVxv7T4eWXWoxjGPibAoRNVswrPvTGFVJVSiW23ud30lCGg8Eq3r2Fzq6pdjp0
9MMQrSncrpJRUrPCOuqTNu4TW53NaFVdJA0HLkpDRj5adMKYIH54HCo9vE+ghaT9
dnYI6ggrxMJOdfNP29y8HUzjzvV9GBcH0aQEdlO1frr+tEt+PsDFiq+SqU1dU+Y2
yacSVqH+j5EEM8vNLO2mJzsukl07ksbICMJhyBqeUSRP8jUSa+QyZleueiksvTpU
HOdos415JrkeAYr+K6qNleefmrXZnX2zwpvz5grW4YXLB9vn97ClAhWrd12x4Xps
qTiGH69knxB4qomN4Dm7SW7WvBGg71o4MILcFqZ/Eh/GXQ7/i03Kig/PO6zd0hPK
4XtaLAX0qqy9PJLKaYtu1Yg7IL+PRx9lyOrSHtZoCwDICoQD0hn3EkoVHEoLrmin
7nJ1SruikV+JOf1TxTiR
=jt/A
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Tom Wijsman-2
In reply to this post by hasufell
On Sat, 22 Mar 2014 23:48:06 +0000
hasufell <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Alec Warner:
> > https://wiki.gentoo.org/wiki/Package_Tags
> >
> > Object or forever hold your peace.
> >
> > Or argue for 100 posts, either way.
>
> Sounds good, but how do we get consistency in there? I mean... this
> only works if we have some sort of consensus about tag names, at least
> more common ones.

By aggregating a global list of tag names; that way, when you tag a
package you can look for tags on the global list that apply to it, and
if it happens two different ways to name something were brought up you
can also discuss it with one another. I don't think the inconsistency
would become of a size to be concerned about; but yes, at the very
least we need to watch out in the beginning to not let it happen...

Though, choosing the right tag naming early on might be a need for
this to succeed; maybe we can brainstorm some examples of how packages
would be tagged, to get an idea about it.

--
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : [hidden email]
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Tom Wijsman-2
In reply to this post by Alec Warner-2
On Sat, 22 Mar 2014 15:33:27 -0700
Alec Warner <[hidden email]> wrote:

> https://wiki.gentoo.org/wiki/Package_Tags
>
> Object or forever hold your peace.
>
> Or argue for 100 posts, either way.

A possible problem with this would be whether much maintainers would be
concerned enough to spend their time on this. By spending time thinking
up with tags you give to a package, you lose some time working on a bug.

Adding some quick tags one can think of does "something" when you're
busy; but I'm not sure if limited time would yield a good set of tags.

Crowdsourcing, as brought forward[1] by rich0, could yield a far more
rich set of tags; together with a small bit of moderation for quality.

 [1]: http://article.gmane.org/gmane.linux.gentoo.devel/90693

--
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : [hidden email]
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Alexander Hof
In reply to this post by Alec Warner-2
Alec Warner dixit:
> https://wiki.gentoo.org/wiki/Package_Tags

Without expecting to have any weight on the discussion, I just wanted to
let you know: As a system maintainer I like to use the categories, e.g.
when doing 'eix -I media-fonts/' or in package.use 'media-fonts/* X'.


Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Ciaran McCreesh-4
In reply to this post by hasufell
On Sun, 23 Mar 2014 00:04:08 +0000
hasufell <[hidden email]> wrote:

> Ciaran McCreesh:
> > On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner <[hidden email]>
> > wrote:
> >> https://wiki.gentoo.org/wiki/Package_Tags
> >
> > And do what with them? Right now this is a solution without a
> > problem.
> >
>
> Finding packages. Descriptions are not consistent, categories too
> generic.
Please explain, with examples, how tags will help with this.

--
Ciaran McCreesh

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ciaran McCreesh:

> On Sun, 23 Mar 2014 00:04:08 +0000 hasufell <[hidden email]>
> wrote:
>> Ciaran McCreesh:
>>> On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner
>>> <[hidden email]> wrote:
>>>> https://wiki.gentoo.org/wiki/Package_Tags
>>>
>>> And do what with them? Right now this is a solution without a
>>> problem.
>>>
>>
>> Finding packages. Descriptions are not consistent, categories
>> too generic.
>
> Please explain, with examples, how tags will help with this.
>

When thinking about games, it is pretty obvious and common practice on
almost any gaming platform/service like steam. You can't just say
"this game is an rpg"... it may be a mix of genres. Tags may even
identify features like "multiplay". USE flags cannot deliver that,
because there is no "multiplay" or "3rd-person" flag for obvious
reasons. Descriptions try to be short and and give an idea what the
game is about, not list all the possible genres or common search terms.

It also works the other way around. There are a lot of applications
that are scattered across multiple categories like terminal emulators
or file managers. The user ends up searching the web or wiki instead
of using portage tools which would be far more efficient.

so we have:
* tags to extend categories, e.g. when a package might fit in more
than one
* tags to group similar packages which are scattered across multiple
categories
* tags for features or attributes that cannot be expressed by USE
flags and cannot be guaranteed to be part of the description
* and so on
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTLtt8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgn3QP/0KLFi6Zdv/OkdwMi05gXqlr
NHnHAPf2v83gTeAikBaXRq+P11wWzraUPMrQBNe6agU2VmQGpJTt97KrVzzXJAuQ
ND1W2Dne6wV/c61UY/KDnGExb9QSXi6ow5eNZoJjoX1sUEorXaNDlI57sYaywlny
auT45Vhp87jwJLFydM4dGK4girbqSPR145bLumdB1fj5PGKc9z3e8MT2MQ+4UgYo
m4VGWxoJ//j6TX6Wv5zk0WJRPVoRdOqcTcficp90Km56d+eDV9Ijx5K0ZIQ46+7z
zj0xZvCLGKYsELgQlXHrCHrhYH12xkyo54WzVP2SpLN7AldKs73qr+Ntst3cLxUw
HL7inMHzRJoGsGbuYVXPzfOyDC23LDaofJrMjdny/vrUfA/I+Iu6NgAjAcy59QaC
QtW/DIpoZtosHSz6Bh4UG89a/KwhgVzPyJ2C/On0FtOv6oJmGjuCRj3SfH1hM5s8
6D3DYxXDFjfJR8WPrnTpwyMDaPgMP1Aow+WowEHFnp9ApBa8at1QONJm020SBZZx
f7vSi6Iu6C34kg6dzojuVQoSoP/wpzWDksh9hNRhrZnsefpjZRCN5cCjMqMI30ua
ZTU7vVG1BAeUjB18EzPIccLrk/2Tv8QDYvIRnNHsFWdedOQK7t5cbIo9tmIpYmNb
ucdX2RTAXEoxjN/dCgIV
=SPv7
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Duncan-42
In reply to this post by Ciaran McCreesh-4
Ciaran McCreesh posted on Sun, 23 Mar 2014 12:02:58 +0000 as excerpted:

> On Sun, 23 Mar 2014 00:04:08 +0000 hasufell <[hidden email]> wrote:
>> Ciaran McCreesh:
>> > On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner <[hidden email]>
>> > wrote:
>> >> https://wiki.gentoo.org/wiki/Package_Tags
>> >
>> > And do what with them? Right now this is a solution without a
>> > problem.
>> >
>> >
>> Finding packages. Descriptions are not consistent, categories too
>> generic.
>
> Please explain, with examples, how tags will help with this.

One classic example in such discussions is kde's kmail and gnome's
evolution.

A package can have only one category so for these, the packager must
choose either the appropriate DE category (as with kde-base/kmail) and
leave it unlisted in the appropriate functionality category
(mail-client), or alternatively, choose the appropriate functionality
category (as with mail-client/evolution), and leave it unlisted under the
appropriate DE (gnome-base I guess it'd be, since the evolution modules
are in gnome-extra).

But that limitation goes away with tags as a package could have as many
tags as people found appropriate, so whatever category the packager
chooses, it could have both tags and thus be discoverable in either spot.

That does imply that at least one set of tags would correspond roughly to
categories, tho a single kde tag for example, vs kde-base and kde-misc,
would arguably suffice.  But tags wouldn't need to be limited to
categories...

The glep should probably be expanded with several examples like that.

(Tho don't construe this to say that I'm in favor of the idea.  I'm
neutral in general tho slightly negative as I think there are better ways
to spend one's time, but gentoo is volunteers, and volunteers spend more
time when they're motivated, so it's not a zero-sum game and if enough
people are interested enough to drive it forward, go for it!)

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Jeroen Roovers-3
In reply to this post by Alec Warner-2
On Sat, 22 Mar 2014 15:33:27 -0700
Alec Warner <[hidden email]> wrote:

> https://wiki.gentoo.org/wiki/Package_Tags

   "This GLEP author would love to blight categories out of gentoo
    history as a giant mistake."

Why?


     jer

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Alexander Berntsen-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/03/14 15:46, Jeroen Roovers wrote:
> "This GLEP author would love to blight categories out of gentoo
> history as a giant mistake."
It does not matter. Just remove that line. It is irrelevant.

- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlMu98oACgkQRtClrXBQc7VElwD/Siuqz64ggZ23xZ7904sbgcrG
Hkjp62BFzo8/LW5aHhMBAKiME3FuPuY+Ev4o5o/2j5QsKasHjPh0vuiCcHGoTY+N
=pPnG
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Alec Warner-2
In reply to this post by Tom Wijsman-2

On Sun, Mar 23, 2014 at 2:45 AM, Tom Wijsman <[hidden email]> wrote:
On Sat, 22 Mar 2014 23:48:06 +0000
hasufell <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Alec Warner:
> > https://wiki.gentoo.org/wiki/Package_Tags
> >
> > Object or forever hold your peace.
> >
> > Or argue for 100 posts, either way.
>
> Sounds good, but how do we get consistency in there? I mean... this
> only works if we have some sort of consensus about tag names, at least
> more common ones.

By aggregating a global list of tag names; that way, when you tag a
package you can look for tags on the global list that apply to it, and
if it happens two different ways to name something were brought up you
can also discuss it with one another. I don't think the inconsistency
would become of a size to be concerned about; but yes, at the very
least we need to watch out in the beginning to not let it happen...

Though, choosing the right tag naming early on might be a need for
this to succeed; maybe we can brainstorm some examples of how packages
would be tagged, to get an idea about it.

This is basically the same problem with USE flags. Personally I also dislike global USE flags on multiple levels, so I'm not entirely interested in tag consistency. That being said, I wouldn't object to such a feature very strongly. I don't consider it a blocker to GLEP adoption, merely a concern that we can address later.

-A 

--
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : [hidden email]
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Alec Warner-2
In reply to this post by Tom Wijsman-2
On Sun, Mar 23, 2014 at 2:57 AM, Tom Wijsman <[hidden email]> wrote:
On Sat, 22 Mar 2014 15:33:27 -0700
Alec Warner <[hidden email]> wrote:

> https://wiki.gentoo.org/wiki/Package_Tags
>
> Object or forever hold your peace.
>
> Or argue for 100 posts, either way.

A possible problem with this would be whether much maintainers would be
concerned enough to spend their time on this. By spending time thinking
up with tags you give to a package, you lose some time working on a bug.

Adding some quick tags one can think of does "something" when you're
busy; but I'm not sure if limited time would yield a good set of tags.

Crowdsourcing, as brought forward[1] by rich0, could yield a far more
rich set of tags; together with a small bit of moderation for quality.


Crowdsourcing poses its own set of problems, most of which I'm not eager to design software around.

I'd rather deploy the GLEP, wait 6 months, see if it failed, and if so, do something else (or nothing else, and simply repeal it.)

-A
 
 [1]: http://article.gmane.org/gmane.linux.gentoo.devel/90693

--
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : [hidden email]
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

hasufell
In reply to this post by Alec Warner-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Alec Warner:
> On Sun, Mar 23, 2014 at 2:45 AM, Tom Wijsman <[hidden email]>
> wrote: so I'm not entirely interested in tag consistency

What are they for then if I cannot efficiently use them to search for
software? (which I cannot, if there is no consistency)

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTLzRjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAg0QMP/jhl0WmdDqDLB38uK1+G5Q8R
Q5KhfDPikq0oeVRsxRIa37MQkVpDKzawKPYc1ITOAZ5P2vVRGTe+QiB7R/Ul8r2j
253o5gDZn17zsi7koHrF2T+XgDhT4OEJExVH49GT7XEvpxtXIl7y4T22dlghD2H4
nzLyJExW1eAao7TAAV2SVCiUskW8Ex07ei1yAYBodxcAHV4W8M74aZ6KiB81vYhm
SxnXiQfKHYwzE7aQMMd5yefmDFA34OCH1PDXXI7PNtKUW1u771cmg/RuHVp4Ekdp
badVqbKU5SrnPocg78hQRSpJSBPkI1N96v8Le1FDfjU0q+Q+G9a8ml+KkybQORFR
CN+fU7yO9bs/r+/wb3Jzicn2LqFbLXX7j66NBuzUBVxHACBSyeqMi4yK58ZPi/rg
LjxZ1wqb7zfW710DSICwUJyNrufQBgbzl4T0OtJPN45oE5HW8POXX2JZeIWiZLcF
O3GdnZ/gkWcbVOGHjjAAWRiBkI7uReDsGL34nbOcVj1fZFh4fp1CUhIG1N1v3GNe
8MZY73zopE8wMRb+27H9ZTMt/jlDcpshJZ5mjrOkRTI8yjYxIFeBVokO6yUSEktg
aBlPwhtMjlQ0KdUO2o86BAK26/BaguLhN8MCHimZbU5DOA6fp1P7lOqVg5Qzzn7k
uGtRoAylQi13O2kXSOLW
=/mYw
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

hasufell:
> Alec Warner:
>> On Sun, Mar 23, 2014 at 2:45 AM, Tom Wijsman <[hidden email]>
>> wrote: so I'm not entirely interested in tag consistency
>
> What are they for then if I cannot efficiently use them to search
> for software? (which I cannot, if there is no consistency)
>
>

That said... if it's not about search terms, but rather about listing
all tags of a single package, then it's pretty useless and people
should rather use "longdescription".
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTLzVoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgmAsP/18uMwgHRtEdMHyHAITvUFO+
1O1orSM78BUEfEQrXozD+OJ4BnOFChBTY2ue1BlVRB7l39HV4BfQwXtYLJl6oisG
w4tJestVsSPsPDm1ke3zPqXzGk0QN+jsv/MnZQd/EyKyEh97icewKVifYFuQe1Ta
fVhxHDLKIM0GJRsWnhrv6z06kMEVvUZcOg0wq6TysPx3YKe/2igG9aApNJdndxbK
1SNRNwkEzuHiuMZpwGuiyFFU7J0Q3YSl2yf4BLU9wxgD7K8XDoAF495EZovo2XhU
/Mua/RqOXLFMF/Axr82j+WPpUKtXREHl1JiVRytYC0iHhcyiHLhmv6TaOW01odPK
BsMxP4NIKfIIhWk+WadXNgFmop42Nd/g+5N8b3BcHloDetSJRPVxOL6N/KAPQEXR
x+J29XVXX+GE8pnNDJlvS930/I5dyabDKrQJwmh4eWZChFTjD+5lfndjWF4YHMvj
bN6kGibBfI6EQ6VqUJZ6LRgC1NYzFqeH4scR1kn4WT6DoSJw1O0KviZ8i2imr3+5
Ey1UtTZY8g+Npcv6oU1yCbqqhcudQqLSq01b9Lp/yNWVfRShpl8TshGcqcCtstEh
5FJLghXUNoucHMSUWlIcDSkXWQdlMddG4AWFs33gQAqC942FbaWKObfJV05rwXuN
T2IysJBrXVb7ZDsCrsz8
=PYYp
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Michał Górny-5
In reply to this post by Alec Warner-2
Dnia 2014-03-22, o godz. 15:33:27
Alec Warner <[hidden email]> napisał(a):

> https://wiki.gentoo.org/wiki/Package_Tags
>
> Object or forever hold your peace.

Honestly, I don't think metadata.xml is a good place for it. While I
like the consistency with general use of that file, I feel like it's
going to make the application of tags more cumbersome, more noisy
and make it harder to maintain consistency.

As I see it, tags are not the same kind of package property
as the description or package name. As I see it, current metadata.xml
properties are somehow constant. They are usually set
by the maintainer, do not change often and are strictly related only to
the package.

Tags, on the other hand, are more 'live'. They place the package
somewhere in the 'global' tag hierarchy that can change over time.
I expect that people other than maintainers will be adding tags to
packages (and changing them), and that people will invent new tags
and apply them to more packages.

So, first of all, your solution would mean that every commit adding
a new tag or changing one of the tags would modify the package
metadata.xml. This means a Manifest update and a ChangeLog entry (please
don't get into more rules for ChangeLogs now), and this means it will be
harder to find actually useful entries there.

So we make tag updates harder, and increase time and size of rsync.

Secondly, since tags for every package will be held in different files,
people will need dedicated tools to collect tags from all those files
and add matching tags to their own packages. Long story short, we're
going to have many 'duplicate' tags that will require even more commits
with ChangeLog entries and Manifest updates.

Worse than that, your GLEP doesn't even have any basic rules for naming
tags -- like what language form to use and, say, which character to use
instead of space. This sounds like the sort of things that's going to
make it even harder to get some consistency, especially if some
developers are going to follow someone else committing earlier and some
will follow their own rules.

I'd honestly prefer that -- if we should really keep tags in the tree
-- to do that with a single 'metadata/tags' file or some kind of
hierarchy there. Keep them outside the package directory -- bind
packages to tags, rather than tags to packages. Keep all the commits
in a single place without altering the ebuild work flow.

--
Best regards,
Michał Górny

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Michał Górny:

> Dnia 2014-03-22, o godz. 15:33:27 Alec Warner <[hidden email]>
> napisał(a):
>
>> https://wiki.gentoo.org/wiki/Package_Tags
>>
>> Object or forever hold your peace.
>
>
> I'd honestly prefer that -- if we should really keep tags in the
> tree -- to do that with a single 'metadata/tags' file or some kind
> of hierarchy there. Keep them outside the package directory --
> bind packages to tags, rather than tags to packages. Keep all the
> commits in a single place without altering the ebuild work flow.
>

That sounds better. That way it is also easier to get some
consistency. E.g. tags can be discussed... but adding packages to tags
is up to the maintainers.

The GLEP should maybe cover a basic set of tags. Then projects like
games, science etc could add their sets as well which may be a bit
more specific... instead of random maintainers adding random tags.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTLz8xXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgYpsP/ip5e4Jf1WmU3ThkQmLTu8p2
j67H8RNciPIrxnhhqCtl86mVVsBYKnMA1jwQI/5Yu1aqXnjTM+mEpwbWmas79vm5
0Djam0584DUDCcxkQPUFBs0qmxcWKzQOtClONPWbdgRryKS0csBoDhrJX1JtA3aQ
Cn5Nj1psgaMlS/YeezQI1IVnIJIHaSuJ5v4AQZCwKofuMAeQvhFa3WaZVMcApJxj
ARABa4ZQ3kt7baL0J9/L9vmMbGZ0mWb0K0qGZ9kqhkUtRIgC2fhXad1haIHlcyGB
diXh5UyJgwHKuYKJ1OcmsVHc1EtueJUWCWoRsOQduRfcHahdRhkRh0+zk3HW6hq2
5m+GMrYzFkBBYcfZmFpCK2ElYQ4Pk4rncagLavry7THY/7+8MlTNhdGKMTHo99nk
M5WzcZI1S24sY5h/vZHIkpx2IS+gZE5+9FpJ2H76uu+hk7vU8t2owjZcret1FbZ9
sM4DgmSjDkMWNWDBVlyIiCDoT0VKFEG+8rNa1o9msnrbpyIu7xHHNcgPG5Xvx2Rk
ebatg8mq/qPQMEFOwICej72q1AbeXZcEPxKuL13g5RcDAHMjlPfL0pzN8g341+i+
UepHoU/RK30sd+Kp+NsLIS+RKesuujNS7DQa8FOtr8GuP0sAo4BdV+syT6avKK8A
ixYiHLmcm4Y1eTdV6e20
=Q5/K
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Joshua Kinard-2
In reply to this post by Michał Górny-5
On 03/23/2014 15:44, Michał Górny wrote:

> Dnia 2014-03-22, o godz. 15:33:27
> Alec Warner <[hidden email]> napisał(a):
>
>> https://wiki.gentoo.org/wiki/Package_Tags
>>
>> Object or forever hold your peace.
>
> Honestly, I don't think metadata.xml is a good place for it. While I
> like the consistency with general use of that file, I feel like it's
> going to make the application of tags more cumbersome, more noisy
> and make it harder to maintain consistency.
>
> As I see it, tags are not the same kind of package property
> as the description or package name. As I see it, current metadata.xml
> properties are somehow constant. They are usually set
> by the maintainer, do not change often and are strictly related only to
> the package.

IMHO, metadata.xml is actually the best place to describe a package with
tags, but I am not so sure it's the best place to "define" a tag.  I guess
if we automate the indexing of tags, much like how use.desc.local is
generated from metadata.xml, then that might eliminate some of the
maintenance overhead.

The only way tags are going to work well is to keep the management of them
as automated as possible.  They should only be involved in searches for
packages, and nothing else.  E.g., hypothetical emerge command might be:
emerge -T mail,client, which will show me all packages with the tag of
'mail' and 'client' (I didn't check emerge to see if -T already has a
purpose, btw).

And I think we should limit the number of tags allowed per package to a
reasonable number.  Maybe five tags maximum?  StackOverflow is one example
where they restrict questions to five tags.  In addition, SO tries to
suggest to you already-existing tags so that you reuse them instead of
creating new ones all the time.  Repoman could be extended to issue a
warning when metadata.xml contains previously undefined tags and optionally
display a match of similarly-named, existing tags (if only to catch
misspellings, 'mial' or 'cleint' instead of 'mail' and 'client').


> Tags, on the other hand, are more 'live'. They place the package
> somewhere in the 'global' tag hierarchy that can change over time.
> I expect that people other than maintainers will be adding tags to
> packages (and changing them), and that people will invent new tags
> and apply them to more packages.
>
> So, first of all, your solution would mean that every commit adding
> a new tag or changing one of the tags would modify the package
> metadata.xml. This means a Manifest update and a ChangeLog entry (please
> don't get into more rules for ChangeLogs now), and this means it will be
> harder to find actually useful entries there.
>
> So we make tag updates harder, and increase time and size of rsync.

Instead of individual <tag> lines in metadata.xml for each tag, why not a
single <tags> line that contains a comma-delimited list of up to five tags,
whitespace optional?  That should help reduce the "fluff" of the tree by
adding this feature.

E.g.,

<tags>one,two,three,four,five</tags>

vs.

<tag>one</tag>
<tag>two</tag>
<tag>three</tag>
<tag>four</tag>
<tag>five</tag>

(36 bytes vs. 82 bytes)


> Secondly, since tags for every package will be held in different files,
> people will need dedicated tools to collect tags from all those files
> and add matching tags to their own packages. Long story short, we're
> going to have many 'duplicate' tags that will require even more commits
> with ChangeLog entries and Manifest updates.

If we automate the generation of a master tag index file, like
use.desc.local, this can be avoided.  emerge can simply go rummage through
the master index for matching tag entries instead of going through the
entire tree.  Because if we wanted to sift through the entire tree, grep
would be a far better method (compiled C and probably better text-matching
algorithms than emerge).


> Worse than that, your GLEP doesn't even have any basic rules for naming
> tags -- like what language form to use and, say, which character to use
> instead of space. This sounds like the sort of things that's going to
> make it even harder to get some consistency, especially if some
> developers are going to follow someone else committing earlier and some
> will follow their own rules.

Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no
spaces.  A lot of problems are avoided if we keep tags to one-word
descriptors only.  E.g., for mail clients, they would carry both 'mail' and
'client' as two of their five tags.  For kmail, a third tag would be 'kde'
and Evolution would have 'gnome' instead.


> I'd honestly prefer that -- if we should really keep tags in the tree
> -- to do that with a single 'metadata/tags' file or some kind of
> hierarchy there. Keep them outside the package directory -- bind
> packages to tags, rather than tags to packages. Keep all the commits
> in a single place without altering the ebuild work flow.

While I definitely like the idea of a single, master file, I feel this could
run away pretty quickly as it's continuously updated.  For example, adding a
new package, a dev has to now remember to add the new package's relevant
tags to this file, and remove its entry when that package is removed from
the tree.  By auto-generating this file from metadata.xml contents, tag
management is more evenly distributed to individual package maintainers, who
just have to remember to add the relevant entries to metadata.xml for their
package's tags to get indexed, and when a package is removed, its tags will
also be removed.

I'd also suggest that 'all' be considered a default, global tag for all
packages, it be a reserved tag internal to emerge and other package
managers, and not count against the number of allowed tags (meaning that
technically, a package is allow five tags + 'all').

As for default tags when a package does not define any, the package category
gets split at the hyphen and becomes two independent tags.  This is
overridden when at least one tag is defined in metadata.xml.

--
Joshua Kinard
Gentoo/MIPS
[hidden email]
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

123