RFC GLEP 1005: Package Tags

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

Re: RFC GLEP 1005: Package Tags

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

On Mon, 24 Mar 2014 15:25:12 +0100
Jeroen Roovers <[hidden email]> wrote:

> On Mon, 24 Mar 2014 12:36:19 +0100
> Jan Matejka <[hidden email]> wrote:
>
> > Categories are essentially tags, only less powerful as they can
> > express relationship of 1:N while tags are can express M:N
>
> No, categories are essentially directories.

fixed: categories are essentially also directories.

same thing, 1:N relationship without symlinks and other misuse of
filesystem.

> I was asking about tags, not about categories.

The original mails are:

> On Sun, 23 Mar 2014 15:46:09 +0100
> Jeroen Roovers <[hidden email]> wrote:
>
> > 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  

> Categories are essentially tags, only less powerful as they can
> express relationship of 1:N while tags are can express M:N

How is this a question about tags and not categories?
 
> It appears it's very hard to answer the simple questions of why we
> need tags and how we would use them. The answers should typically
> involve some explanation of how you're going to use the things once
> you have them.
>
>
>      jer
>


- --
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJTMSouAAoJEIN+7RD5ejaho4AH/1YFbArFwx6t8OoI8yrWCulA
LDt5qBAcZiJoqV9H1V5YdNgcNiLDKIyTCPbkWc4obkgRuNVIJxFAe+duYRQydudW
6KKS2lYQXWSkbDRmJTWOt7BnerHyemvk6AluQn741a2uPZyUI//FPQL8fZkYlR6i
3HFFlW0dI6PHa/9Np8G+RBAs29e8qAR7QKQzDLd9BF/s+6KIK2/FO8pAgMdZBVKk
jJ4Aq1AuRsqrdY0HO940Boiy0ylBFjxB27ej59UmjAzvyOMj9YRf1LqNkgMABENu
ohEckguSryOpBjjD2ZaZrfMbbJTGqfVgz44nhT0s6Nbocb5RmVYp988GIwFQCg4=
=1uIP
-----END PGP SIGNATURE-----
yac
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

yac
In reply to this post by Alan McKinnon-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 24 Mar 2014 09:32:40 +0200
Alan McKinnon <[hidden email]> wrote:
>
> Who is going to approve/disapprove tagable attributes and the tags
> themselves? How will you resolve disagreements people have?

Sounds like a job for QA

>
> What about the case of a package maintainer that simply can't be
> bothered doing tags at all?
>
> I'm not against tagging per se, they can be useful. But they do have
> to be strictly controlled otherwise things get out of hand very
> quickly. Every case I've seen of software that uses a freeform
> tagging mechanism fails almost instantly as it becomes very
> inconsistent. I have one of these apps in a corporate setting right
> now, have you any idea how many ways people can come up with to tag
> the concept of "cloud"?

Some of these could probably be detected by meeting a treshold in
Levenshtein distance (or some variant of) and making a suggestion to
consider found alternative before doing the commit

- --
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJTMS9uAAoJEIN+7RD5ejah5bIH/i6dERPVS2i/rd76HQRHjynr
w7C4N5OQi+cN339f2/JusPwxrfBrUiN7ulsgWACMPz4s8/ZA9yrsRRnqvC2P8bnR
25n94z0vUZa3K5V3MIuDugfKa6nwVY9gZHZj6BP8KNnl84ETasxpG5lR3XTqs0az
4pJG18rbwtk22+7q38hXQv9/vRfAZH3Lx5ilG1+F0+I39miXW6ylsS37ovkdrQ97
rUvNasT+5GcB6jd3tXDQuOJs8UgGuBNgTjzZfrk5Y+6+Dqj2oL5ERRONOS6UN5RB
TYGw9KI1Rj7pRWE1gIi/fhoXbugj0DZArRC8fA3D2NEyYFIStopjI0hI3bXljFs=
=Z9+y
-----END PGP SIGNATURE-----
yac
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

yac
In reply to this post by Joshua Kinard-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sun, 23 Mar 2014 17:40:20 -0400
Joshua Kinard <[hidden email]> wrote:
>
> TBH, I don't like the use of XML at all.

No, we don't need to go one level (format) deeper.

> The 'all' thing is probably unnecessary

What problem does having 'all' tag solve? Seems pretty useless to me.

> Granted, a tag of "dev" offers no value (dev-python ->
> 'dev','python'), but if you were looking for a web browser versus a
> web server, having default tags of 'www','client' or 'www','servers'
> helps for packages in www-client and www-servers.

This might be helpful but rather as one-time, initial, hand-picked
generation on case-by-case (by the category) basis.

> I've always wondered is we allowed portage to have one additional
> level of nesting if that'd help any (i.e., games-* -> games/*).

Squashing games-*/ to just games/ and defining genre by tags. Seems
pretty doable, I like this.

- --
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJTMTZeAAoJEIN+7RD5ejah85gIAItDtxuEntu2nhb4uvltKHfu
dpnT0KePuAZKwV8H59jRx7AovfMo9nTjqs88Sgw6v9NbbKNxRmW3PPWmuJUnLniU
eG31vMsUJ1CgXxNLWaXaYZRi1QTYnJqJM5LDnfFsh4mj9Dk7t1/XCA6rKcICO3qQ
sqEDaSAyOYLBsTGPOyC2trrZNAsLEu2oLImzECXNHa6tNMJt75BJdGfKzFDTGBtF
XiG/qi2IV7ClYxVZP4W1LwN+SVUmLiEDUyMeP6FRgVdEmZcdlQGLm6kBiYD0A/2F
xeWHPoQpgkPRZuLRNv0vvvatO+A2KpXY1rs0s3BYb0xk3MDEGwE+X1ZrcDRVsIg=
=5YXb
-----END PGP SIGNATURE-----
yac
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

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

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

It might be worthwile to prototype this functionality as an
external service.

1. It should be easier to crowdsource the tags definitions, assignments
   and QA and therefore helps to build consistent database faster and
   easier.

2. decouples tagging from maintaining a package, therefore makes more
   community driven and prevents "THAT'S MY PACKAGE, DON'T TOUCH IT YOU
   SCHMUCK" type of quarrel.

3. Classic prototyping benefit - might identify problematic areas for
   implementation.


The downside is the implementation might be more time consuming
depending on architecture. Mostly due to 1. I guess but that could be
handled by using git and pull requests for crowdsource and then the
implementation should be basicly no different from using portage
itself, besides using different VCS.

- --
Jan Matějka        | Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJTMTicAAoJEIN+7RD5ejahIlsH/1UmMa1P+QBEZ/HpfOPX1d4Z
S0nYho8vinPQVenOXMY/0KVvh4bzhmrTZWm4itLVB/5taI88m5fzQbvYSNlEn+Nn
zRTcmyuze+3mmDf3++mfzzjmByYLiYJwCdhNF7HH4V04Ph/aEQbjO++9EL37bW/J
uCYs8b0Vtn97utW2mJcUa7Wbgluo6jhCDHW8yGuZW4JfCo6bRQfqqlxGGGufIXK9
N8FX01Kbt2HFqgwdK7uZIfn0Gh9xGkIL2Jk2WCFzUHjZgJTy0UuPGeUSCOsTt7wg
CcETDWrzscuydtdhZaFmtZ3Xs7eQ7I98nwEdlkSdgbsfQFYQlPvomCGZyGehtTo=
=ykWo
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

hasufell
In reply to this post by yac
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jan Matejka:
>> I've always wondered is we allowed portage to have one
>> additional level of nesting if that'd help any (i.e., games-* ->
>> games/*).
>
> Squashing games-*/ to just games/ and defining genre by tags.
> Seems pretty doable, I like this.
>
>

Sounds like a huge waste of time. And have fun doing all the pkgmoves
in CVS.


However, I think we can agree that the GLEP needs some more work. But
it seems the majority is interested, so don't give up.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTMaRjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgvmIQAOlsgvQqTL6ce3MX2mMruNeh
GCJcIOZl/aPZA9wg3oo1wWqdC1+ZCFf4gWcmi604P1WcPAcWfiJPgvjpLiQ0NTmR
2Ru7iHHEVoHa6x6xqm9+LeMDVFe2dPdL4mNL0KCAWmSLkmZSxPEXmh+AR+xxnSNg
RJvqY5mrb/u2bzyLzLtbmtaaKa/5+lT8sI6cn76Z9MZavQA6ormDX78e2XoD44CJ
TV/COWWngOx8GB3NhyNxbSOdjAvKBGgQpCk/oAIZ0xW4lCiUOFpKJERGk//dbC7h
BpveJuA8TR1Htn9a914o91TJF1l4eC7mF0lB0oDDE5MVgEv1RjS5EjBJoaxahWtm
aEVLXWV1tlfg6GWIzSqW9vhLXeseS2KeAuJr7rG/3wR7T8c//XytCw8DW6SsK6z5
tsfyKtscrm+I/lT8VoIqpTlOmcJ6kkHqLLQkc3sKZDT7ynKWhNghDj/OahcFdZ8L
rWiKZ+RZHLOpdj09gJDGq8fzLCGca0WX2MvjA0bgdVoMzBvzYxnz8qDHtUGGZHU5
/BX6nu0RL/neF1p+XFCtHJaPodcJkia8jf9QmcJufWr2y2g0vpXTpm2GE32t3e+b
8jP/WG46RZCmydLCzVRyYs5qUFgbgDZLJwKL4rnxK3dOd1wpX3HnIW+A1q7P3cmw
sZfn+0YanuAsw3AdhsFk
=kAA7
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Jeroen Roovers-3
In reply to this post by yac
On Tue, 25 Mar 2014 08:03:08 +0100
Jan Matejka <[hidden email]> wrote:

> > No, categories are essentially directories.
>
> fixed: categories are essentially also directories.

Also? No, categories are *essentially* directories: they keep files
apart that should not go together. In precisely that way, their names
happen to aid in building unique atoms, which you need to be able to
tell a package manager (or development tool) which precise bunch of
files you want to read/address/target/modify/etc.

They are *also* other things, like identifiers for actual categories of
packages (hence the name), which may or may not suit someone's needs in
finding packages based on keywords.

Stating in a GLEP that they're a "giant mistake" means you'll have to
polish the document till you have rephrased that into something true
and acceptable, or until you have purged every mention and reference of
the "giant mistake" because it does not serve the purpose of the GLEP
at all.

Categories are *essential* to the way the repositories now work, and
they're not going away, especially not by way of this GLEP. See below.

> > I was asking about tags, not about categories.
>
> The original mails are:
>
> > On Sun, 23 Mar 2014 15:46:09 +0100
> > Jeroen Roovers <[hidden email]> wrote:
> >
> > > 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?

> > Categories are essentially tags, only less powerful as they can
> > express relationship of 1:N while tags are can express M:N
>
> How is this a question about tags and not categories?

The GLEP's statements about categories appear to be a straw man. It
basically states that:

 * we introduced categories to aid in finding packages
 * but it turned out that categories suck at helping us find packages
 * so now we need to add "tags"
 * but we can keep categories because they have proven useful for other
   stuff

You seem to be repeating the same illogical argument here. Now don't
fix it here: go fix the GLEP.


     jer

yac
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

yac
On Tue, 25 Mar 2014 18:31:45 +0100
Jeroen Roovers <[hidden email]> wrote:

> On Tue, 25 Mar 2014 08:03:08 +0100
> Jan Matejka <[hidden email]> wrote:
>
> > > No, categories are essentially directories.
> >
> > fixed: categories are essentially also directories.
>
> Also? No, categories are *essentially* directories: they keep files
> apart that should not go together. In precisely that way, their names
> happen to aid in building unique atoms, which you need to be able to
> tell a package manager (or development tool) which precise bunch of
> files you want to read/address/target/modify/etc.
>
> They are *also* other things, like identifiers for actual categories
> of packages (hence the name)
These are all accidental properties of our categories application. I
don't see how they are relevant.

What I was describing is the difference between fundamental properties
of categories and tags.

> which may or may not suit someone's
> needs in finding packages based on keywords.

That's where tags comes in.

> Stating in a GLEP that they're a "giant mistake" means you'll have to
> polish the document till you have rephrased that into something true

agreed.

> and acceptable, or until you have purged every mention and reference
> of the "giant mistake" because it does not serve the purpose of the
> GLEP at all.
>
> Categories are *essential* to the way the repositories now work, and
> they're not going away, especially not by way of this GLEP. See below.
>
> > > I was asking about tags, not about categories.
> >
> > The original mails are:
> >
> > > On Sun, 23 Mar 2014 15:46:09 +0100
> > > Jeroen Roovers <[hidden email]> wrote:
> > >
> > > > 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?
>
> > > Categories are essentially tags, only less powerful as they can
> > > express relationship of 1:N while tags are can express M:N
> >
> > How is this a question about tags and not categories?
>
> The GLEP's statements about categories appear to be a straw man. It
> basically states that:
>
>  * we introduced categories to aid in finding packages
>  * but it turned out that categories suck at helping us find packages
>  * so now we need to add "tags"
>  * but we can keep categories because they have proven useful for
> other stuff
Please explain how is the straw man different from real issue.

---
Jan Matějka        | Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

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

Re: RFC GLEP 1005: Package Tags

Ciaran McCreesh-4
On Thu, 27 Mar 2014 03:53:47 +0100
yac <[hidden email]> wrote:
> What I was describing is the difference between fundamental properties
> of categories and tags.

You are trying to redefine categories in terms of a concept that they
didn't originally represent. From a package mangler perspective,
categories aren't just "a label" for a package. They're fundamentally
part of a package's name.

--
Ciaran McCreesh

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

Re: RFC GLEP 1005: Package Tags

Wyatt Epp
On Fri, Mar 28, 2014 at 1:14 PM, Ciaran McCreesh
<[hidden email]> wrote:
> On Thu, 27 Mar 2014 03:53:47 +0100
> yac <[hidden email]> wrote:
>> What I was describing is the difference between fundamental properties
>> of categories and tags.
>
> You are trying to redefine categories in terms of a concept that they
> didn't originally represent.

No one's redefining anything.  You seem awfully fixated on the history
that forced categories to exist, which doesn't really matter in this
context.  Regardless of any of that, people can and _do_ attempt to
use categories as a rudimentary method of attempting to search for
packages.

As you and several others have so eloquently pointed out, that's not
their "purpose".  Concurrently, from the other direction, myself and
several others have noted that they're thoroughly inadequate for that
anyway.  That's why this topic keeps coming up and why this
(work-in-progress) GLEP exists in the first place.

> From a package mangler perspective,
> categories aren't just "a label" for a package. They're fundamentally
> part of a package's name.
>
From that standpoint, they're even less adequate for lookup; encoding
metadata in names has never turned out well for anyone.

Cheers,
Wyatt

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Ciaran McCreesh-4
On Fri, 28 Mar 2014 15:46:49 -0400
Wyatt Epp <[hidden email]> wrote:

> On Fri, Mar 28, 2014 at 1:14 PM, Ciaran McCreesh
> <[hidden email]> wrote:
> > On Thu, 27 Mar 2014 03:53:47 +0100
> > yac <[hidden email]> wrote:
> >> What I was describing is the difference between fundamental
> >> properties of categories and tags.
> >
> > You are trying to redefine categories in terms of a concept that
> > they didn't originally represent.
>
> No one's redefining anything.  You seem awfully fixated on the history
> that forced categories to exist, which doesn't really matter in this
> context.  Regardless of any of that, people can and _do_ attempt to
> use categories as a rudimentary method of attempting to search for
> packages.
"Giving something a unique unambiguous name" is not a historical issue.
It's something we still need, and a core part of how package manglers
work. You can't just pretend that categories there for exactly this.

> > From a package mangler perspective,
> > categories aren't just "a label" for a package. They're
> > fundamentally part of a package's name.
> >
> From that standpoint, they're even less adequate for lookup; encoding
> metadata in names has never turned out well for anyone.

Things still need a unique unambiguous name. It's that or GUIDs...

--
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 Fri, 28 Mar 2014 15:46:49 -0400 Wyatt Epp <[hidden email]>
> wrote:
>> On Fri, Mar 28, 2014 at 1:14 PM, Ciaran McCreesh
>> <[hidden email]> wrote:
>>> On Thu, 27 Mar 2014 03:53:47 +0100 yac <[hidden email]> wrote:
>>>> What I was describing is the difference between fundamental
>>>> properties of categories and tags.
>>>
>>> You are trying to redefine categories in terms of a concept
>>> that they didn't originally represent.
>>
>> No one's redefining anything.  You seem awfully fixated on the
>> history that forced categories to exist, which doesn't really
>> matter in this context.  Regardless of any of that, people can
>> and _do_ attempt to use categories as a rudimentary method of
>> attempting to search for packages.
>
> "Giving something a unique unambiguous name" is not a historical
> issue. It's something we still need, and a core part of how package
> manglers work. You can't just pretend that categories there for
> exactly this.
>
>>> From a package mangler perspective, categories aren't just "a
>>> label" for a package. They're fundamentally part of a package's
>>> name.
>>>
>> From that standpoint, they're even less adequate for lookup;
>> encoding metadata in names has never turned out well for anyone.
>
> Things still need a unique unambiguous name. It's that or GUIDs...
>

derailed.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTNdltXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgBeoP/A2f7vHUF3eueeeUsbr7tWIT
z9mURgUl7fKsH7ZQ3cHeEqtL4dDWKmM6XRXuCpRgLK7zMQ1AqFiZSoFOMHCgySs2
TWCpZpTEJQfX6KFbyxuF5Y8GUk8nj0UdfOoYRjOUxlqaNyTG95ZaTKTkTM11EbW1
ER7Tpwj7bJeuKEaHWesPF5zXkzPaZxgu8UDwTu6jYSr0KMpw6GeoEuHiL4lBoXNk
LbKWyt0tDIy4U74U1R68U8yFjwkmvUdIdF8khHO77B3/EDn8/V8fwETkkxhh3YZ3
UHTAZFT7/OKkz3XdycXpbbKUn0aPCSev4/W2QY77ZICL6E6NK1zFAWHIrYO+jJQu
jfP0/iZUpmZPpZbwofjbQgqa6jOtgfQdhP5AXQneApzocf74OoV/1/zbSHpyGIII
SiYb/CNrOU4TDDZo0/+8xcc1GFIBlELy4bpa+UwpGBGqF0KYrt9G1kwVK7YBvo1I
vpbQb/8wIF1HBg97JbbPsTPIYGcMMR7UZ/FcoKQoe5FQ6A6uyCqQRWqR8DYCRqoJ
6lOpsEwGcOnJzNOfAP2nmdE0ZOT0Fg+M4mBIdksNBb12i4MVi+q0BPTxxpS7wLnc
dlA2Ix97y3YPqzBIw9l0593e2abSjmdboIRu6I5duy8zJ/OE8YX8scOnNRZWYBSK
9HC8Mt4Hi1yJiv2oYeEA
=ygQ2
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Kent Fredric
In reply to this post by Damien Levac

On 25 March 2014 03:55, Damien Levac <[hidden email]> wrote:
A lot of people already replied to this question: package search.

A trivial example, a user want to know all terminals available in portage. Of course he could try a `emerge --searchdesc terminal`, but then he would get anything mentioning terminal in the description: which would probably include a lot of "terminal applications" which are not terminals themselves...

`emerge --search terminal` just doesn't cut it as "konsole" wouldn't be a result but is a terminal emulator...

On the other hand, terminals are spread through many categories (gnome-terminal in gnome-base & konsole in kde-base to name the most obvious example).

Thus tags are a nice way for user to find the applications they want.


This example for me suggests we'll need to have some kind of process of defining what tags should be used for what things, similar to how we have a process for global USE, mostly, because inconsistency is a bad thing here.

Because looking at this example and the results of `eix -cS terminal`, I see lots of things that may also be ambiguously tagged "terminal" due to being a terminal based application.

Thus, either "terminal-emulator" or "terminal-app" or similar tags seem necessary.

emerge --search tag:terminal-app tag:jabber-client  ( or similar ) should thus result in net-im/mcabber

And now that we're starting to flesh out mock tags that may make sense, it quickly seems we'll eventually want some kind of tag hierarchy.

But as long as the tag is restricted to [A-Za-z-]+  or similar, we should have enough syntactical space to add a hierarchy in later if we find out we need it.

For the sake of avoiding bikeshed, we should avoid hierarchy until we've proven tags are useful and have discovered we really need hierarchy. YAGNI

--
Kent
yac
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

yac
On Sat, 29 Mar 2014 09:39:06 +1300
Kent Fredric <[hidden email]> wrote:

> On 25 March 2014 03:55, Damien Levac <[hidden email]> wrote:
>
> > A lot of people already replied to this question: package search.
> >
> > A trivial example, a user want to know all terminals available in
> > portage. Of course he could try a `emerge --searchdesc terminal`,
> > but then he would get anything mentioning terminal in the
> > description: which would probably include a lot of "terminal
> > applications" which are not terminals themselves...
> >
> > `emerge --search terminal` just doesn't cut it as "konsole"
> > wouldn't be a result but is a terminal emulator...
> >
> > On the other hand, terminals are spread through many categories
> > (gnome-terminal in gnome-base & konsole in kde-base to name the most
> > obvious example).
> >
> > Thus tags are a nice way for user to find the applications they
> > want.
> >
>
> Because looking at this example and the results of `eix -cS
> terminal`, I see lots of things that may also be ambiguously tagged
> "terminal" due to being a terminal based application.
>
> Thus, either "terminal-emulator" or "terminal-app" or similar tags
> seem necessary.
>
> emerge --search tag:terminal-app tag:jabber-client  ( or similar )
> should thus result in net-im/mcabber
You do this by searching for intersection of tags.

terminal ∩ jabber ∩ client

---
Jan Matějka        | Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

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

Re: RFC GLEP 1005: Package Tags

Kent Fredric

On 29 March 2014 09:56, yac <[hidden email]> wrote:
terminal ∩ jabber ∩ client

And now you want *only* terminal terminals, do you have to search for

terminal ∩ !( jabber ∪ client ∪ everything ∪ else ) ?

Or

terminal ∩ emulator 

( Which may include terminals for emulators instead of terminal emulators )

--
Kent

http://kent-fredric.fox.geek.nz
Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Gordon Pettey
And now you file a bug to get that incorrectly applied "terminal" tag changed to "cli", because they don't mean the same thing.


On Fri, Mar 28, 2014 at 4:06 PM, Kent Fredric <[hidden email]> wrote:

On 29 March 2014 09:56, yac <[hidden email]> wrote:
terminal ∩ jabber ∩ client

And now you want *only* terminal terminals, do you have to search for

terminal ∩ !( jabber ∪ client ∪ everything ∪ else ) ?

Or

terminal ∩ emulator 

( Which may include terminals for emulators instead of terminal emulators )

--
Kent

http://kent-fredric.fox.geek.nz

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Wyatt Epp
In reply to this post by Kent Fredric
On Fri, Mar 28, 2014 at 4:39 PM, Kent Fredric <[hidden email]> wrote:
>
> This example for me suggests we'll need to have some kind of process of
> defining what tags should be used for what things, similar to how we have a
> process for global USE, mostly, because inconsistency is a bad thing here.
>
Yes, you want a controlled, well-defined vocabulary.  That's
important.  On the other hand, don't get too bent out of shape about
it.  These things fall over when you start adding dumb arbitrary
restrictions like "there needs to be consensus" or "there need to be
at least n packages beforehand".

> Because looking at this example and the results of `eix -cS terminal`, I see
> lots of things that may also be ambiguously tagged "terminal" due to being a
> terminal based application.
>
> Thus, either "terminal-emulator" or "terminal-app" or similar tags seem
> necessary.
>
terminal: terminal emulators.  Make it an alias to terminal_emulator.
cli: things that have a normal, line-based terminal interface. See also: curses.

It's not hard to choose good, unambiguous tags when you can use
aliasing to shorthand and unify.  That's why it's more important than
implication, because controlling your vocabulary is seriously
important.

> And now that we're starting to flesh out mock tags that may make sense, it
> quickly seems we'll eventually want some kind of tag hierarchy.
>
No.  You really, really, reaaaaaally don't.  At least not in the sense
that you seem to be thinking.  It makes tags annoying to add and
annoying to use, so no one does either and the whole thing falls over.

> But as long as the tag is restricted to [A-Za-z-]+  or similar, we should
> have enough syntactical space to add a hierarchy in later if we find out we
> need it.
>
Don't worry, we won't.  With only the facilities I've outlined in my
first post, the system will scale well beyond a million packages and
tens of thousands of unique tags, so don't worry too much about
exhausting our semantic description space.

Cheers,
Wyatt

Reply | Threaded
Open this post in threaded view
|

Re: RFC GLEP 1005: Package Tags

Maciej Mrozowski-2
In reply to this post by Ciaran McCreesh-4
On Monday 24 of March 2014 16:28:44 Ciaran McCreesh wrote:
| On Mon, 24 Mar 2014 10:55:38 -0400
| Damien Levac <[hidden email]> wrote:
| > A lot of people already replied to this question: package search.
|
| Sure, but can you point to prior examples of this kind of stuff
| actually working?

https://wiki.debian.org/Debtags
http://debtags.debian.net/search/

True, may not be as popular as full-text description search.

regards
MM

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

Re: RFC GLEP 1005: Package Tags

yac
In reply to this post by Ciaran McCreesh-4
On Fri, 28 Mar 2014 20:02:30 +0000
Ciaran McCreesh <[hidden email]> wrote:

> On Fri, 28 Mar 2014 15:46:49 -0400
> Wyatt Epp <[hidden email]> wrote:
> > On Fri, Mar 28, 2014 at 1:14 PM, Ciaran McCreesh
> > <[hidden email]> wrote:
> > > On Thu, 27 Mar 2014 03:53:47 +0100
> > > yac <[hidden email]> wrote:
> > >> What I was describing is the difference between fundamental
> > >> properties of categories and tags.
> > >
> > > You are trying to redefine categories in terms of a concept that
> > > they didn't originally represent.
> >
> > No one's redefining anything.  You seem awfully fixated on the
> > history that forced categories to exist, which doesn't really
> > matter in this context.  Regardless of any of that, people can and
> > _do_ attempt to use categories as a rudimentary method of
> > attempting to search for packages.
>
> "Giving something a unique unambiguous name" is not a historical
> issue. It's something we still need, and a core part of how package
> manglers work. You can't just pretend that categories there for
> exactly this.
I see your point. Resolving ambiguity is certainly needed and
categories are prettier than most distributions approach like prefixing
the package name with "python-".

However, it still seems that besides resolving ambiguity categories are
in part also used to provide information better expressed with tags,
like the genre of a game.

jcallen was kind enough to provide a script that finds ambiguous
package names and prints them with the categories they are in [1]_ and
the output for portage tree [2]_, which supports my suspicion that
there indeed are no ambiguities in game names. Maybe more cases like
this can be found.

.. [1] http://bpaste.net/show/VuEHVqLlLgsfsdL71tuz/
.. [2] http://bpaste.net/show/195029/

---
Jan Matějka        | Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

signature.asc (501 bytes) Download Attachment
123