FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-22-2011, 06:19 PM
Ciaran McCreesh
 
Default Tags (Was: RFC: split up media-sound/ category)

On Wed, 22 Jun 2011 21:55:18 +1200
Kent Fredric <kentfredric@gmail.com> wrote:
> I'd love a tag solution, that'd be nice, is there a GLEP for it yet?
> And if so, how long will it take to get this "tag" feature supported
> by EAPI standards?

The slow parts are coming up with a good design, getting the Council to
approve it, and getting Portage to implement it. The fast part is
getting the PMS bit done.

The problem with tags is that all we've heard so far is "we should have
tags!", with no description of what tags are, what they'll solve or how
they're used.

--
Ciaran McCreesh
 
Old 06-23-2011, 12:57 AM
Wyatt Epp
 
Default Tags (Was: RFC: split up media-sound/ category)

On Wed, Jun 22, 2011 at 14:19, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 22 Jun 2011 21:55:18 +1200
> Kent Fredric <kentfredric@gmail.com> wrote:
>> I'd love a tag solution, that'd be nice, is there a GLEP for it yet?
>> And if so, how long will it take to get this "tag" feature supported
>> by EAPI standards?
>
> The slow parts are coming up with a good design, getting the Council to
> approve it, and getting Portage to implement it. The fast part is
> getting the PMS bit done.
>
> The problem with tags is that all we've heard so far is "we should have
> tags!", with no description of what tags are, what they'll solve or how
> they're used.
>
> --
> Ciaran McCreesh
>

Tags are basically keywords you can use to describe packages, allowing
you to easily search and explore your options based on what the
packages actually does (if we want to get technical, anything that
identifies a package is a sort of tag: name, version, license, set,
checksum, etc.). *It's just a vocabulary that eases the burden of
human lookup. *The categories we have now are essentially (pairs of)
tags tied to a treelike structure in an actual filesystem, and I'd
wager that's a decent place to start, too-- probably the most
prominent problem I can see with the current method comes from these
edge cases where one category is obviously not enough. *The obvious
solution is probably to just stick our semantic metadata into the
metadata.xml. *So for...say, media-video/kdenlive,
<cat>media-video</cat>[1] becomes more like this:

<cat>
<tag>media</tag>
<tag>video</tag>
<tag>kde</tag>
<tag>editors</tag>
</cat>

The canonical tag list needn't even expand beyond what we have already
(for the time being; attempting to keep your vocabulary entirely
static is a Bad Thing. *Humans are amazing at finding new things that
need tagging. *Getting ahead of myself, though).

In the practical sense, we can probably just whip out a quick script
and get 98% coverage; package maintainers should be encouraged to add
relevant tags to the packages under their care as needed.

--Wyatt, hoping this text is plain as it says it is. Sorry if it's not.

[1] Let's just assume for the sake of argument that kdenlive actually
has a <cat> field in its metadata file.
 
Old 06-23-2011, 01:25 AM
Duncan
 
Default Tags (Was: RFC: split up media-sound/ category)

Wyatt Epp posted on Wed, 22 Jun 2011 20:57:47 -0400 as excerpted:

> On Wed, Jun 22, 2011 at 14:19, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Wed, 22 Jun 2011 21:55:18 +1200 Kent Fredric <kentfredric@gmail.com>
>> wrote:
>>> I'd love a tag solution, that'd be nice, is there a GLEP for it yet?

>> The slow parts are coming up with a good design, getting the Council to
>> approve it, and getting Portage to implement it. The fast part is
>> getting the PMS bit done.
>>
>> The problem with tags is that all we've heard so far is "we should have
>> tags!", with no description of what tags are, what they'll solve or how
>> they're used.

> Tags are basically keywords you can use to describe packages, allowing
> you to easily search and explore your options based on what the packages
> actually does (if we want to get technical, anything that identifies a
> package is a sort of tag: name, version, license, set, checksum, etc.).

Umm... I believe Ciaran meant "no description" in the practical PM
implementation rules sense, not in the general definition sense, which I
suppose most folks here understand by now.

Ciaran is, after all, a (arguably the) prime mover behind PMS, defining
the standards to which Gentoo package managers must conform. So his
concern is very likely to be in that regard -- actually seeing a draft
GLEP defining the technical rules in enough detail that the three PMs can
implement it to the point that if they disagree on how a tag should be
implemented and treated, it's clear which one's bugged and which ones
following the standard, so the bugged one can be fixed.

Until that happens, or at least is actually in process, it's all talk.

--
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
 
Old 06-23-2011, 03:20 AM
Wyatt Epp
 
Default Tags (Was: RFC: split up media-sound/ category)

On Wed, Jun 22, 2011 at 21:25, Duncan <1i5t5.duncan@cox.net> wrote:
> Umm... I believe Ciaran meant "no description" in the practical PM
> implementation rules sense, not in the general definition sense, which I
> suppose most folks here understand by now.
>
Most is not all. In general, I try not to assume everyone is on
the same page; one of the things academia got right.

> Until that happens, or at least is actually in process, it's all talk.
>
Shall we call it "in process" right now, then? My impression was he
was calling for us to get down to brass tacks and hammer this out for
real. Apologies in advance for the long post.

As far as what I've said already, a quick read of the PMS tells me
that "[metadata.xml's] exact format is strictly beyond the scope" of
it. Would it be acceptable to add this to the ebuilds themselves?
Otherwise, at least the tags become mandatory and drag the xml into
this. Given that encoding tags into directory paths is why we're
talking about this in the first place, that's out; the third obvious
solution is a separate file for each package, but....yeah, not where I
would personally go with it without thinking long and hard about the
other two first.

The directory paths themselves....well, one solution I noted from the
other thread was to populate tag directories with symlinks. I've done
similar things, but always thought of it as a hack, so I'm reluctant
to advocate for building a deployable semantic system on top of it-- I
could potentially be convinced otherwise, though. Given that tags and
categories have roughly the same purpose and end result, a flat ebuild
directory referenced only by its metadata should certainly be
possible. If this is going to happen, and happen right, what this all
looks like in the filesystem is moot anyway.

I bring this up because there are several packages with the same name
and different qualification. Obviously, they'll have different tags
because they're not the same thing, but neither should they share the
same directory. So the simple solution is to just change the package
names so we avoid collision and preserve our flat ontology (I've
forgotten the objection to doing this; please forgive). The next
simplest solution is to just name the directories as hashes in-tree
and cover it up with software magic (I'm pretty sure this ends up
pretty ugly, implementation-wise).

For the sake of migration, packages should probably have their current
category/directory added to the tags; deprecate and remove after
sufficient time (I think this is one of those two-year changes?).

Those are roughly my thoughts for the time being. Let's do this thing!

Regards,
Wyatt
 
Old 06-23-2011, 06:14 AM
Ciaran McCreesh
 
Default Tags (Was: RFC: split up media-sound/ category)

On Thu, 23 Jun 2011 01:25:57 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> Umm... I believe Ciaran meant "no description" in the practical PM
> implementation rules sense, not in the general definition sense,
> which I suppose most folks here understand by now.

No, it's worse than that. Consider the following questions. Most people
will say that tags "obviously" have a particular answer for each
question, but they disagree on which answer it is...

First: how do tags relate to categories? Are they independent, a
refinement or a replacement?

Second: which of the following are tags suitable for? Searching.
Browsing just using 'ls' etc. Browsing using tools (e.g. a website or a
package manager command). Using as dependencies.

Third: are tags a property of ebuilds, of packages, of a repository, or
entirely external?

Fourth: do tags in any way identify a package?

Fifth: how do overlays fit in to all of this?

From the previous times we've had this discussion, I very much get the
impression that right now "we'll use tags!" is an utterly nebulous
answer to a problem that's about on par with "we'll replace all use of
oil by green technology by next week!".

--
Ciaran McCreesh
 
Old 06-24-2011, 12:07 AM
Wyatt Epp
 
Default Tags (Was: RFC: split up media-sound/ category)

On Thu, Jun 23, 2011 at 02:14, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> First: how do tags relate to categories? Are they independent, a
> refinement or a replacement?
>
I would suggest they be a replacement because categories are just an
overly limited subset of a proper tagging scheme.

> Second: which of the following are tags suitable for? Searching.
> Browsing just using 'ls' etc. Browsing using tools (e.g. a website or a
> package manager command). Using as dependencies.
>
Yes, Maybe, Yes, Probably Not.

> Third: are tags a property of ebuilds, of packages, of a repository, or
> entirely external?
>
Likely packages. Though I suppose the potential exists for a version
change to add or remove features and change tags; so, ebuilds?

> Fourth: do tags in any way identify a package?
>
Uniquely? No.

Regards,
Wyatt
 
Old 06-24-2011, 12:46 AM
Kent Fredric
 
Default Tags (Was: RFC: split up media-sound/ category)

Another question I think that needs be asked, is "What does a tag look
like", or "What sort of values can a 'tag' have?".

People are probably assuming it will be some arbitrary name like
"video" or "sound" or soforth, but there is potential to use tags for
more than that.

Consider ideas such as tag-spacing.

Intent: editing, viewing, processing, validating, etc
Material: video, images, sound, text, etc
Formats: mp3, jpeg, etc.

( ie: it might be useful to list all programs that are known to work
with a given format )

Should this tag namespace be part of the tag itself? Or something different?

/tags/intent/editing/*

or

/tags/intent:editing/*


--
Kent

perl -e* "print substr( "edrgmaM* SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
 
Old 06-24-2011, 06:43 AM
Michał Górny
 
Default Tags (Was: RFC: split up media-sound/ category)

On Thu, 23 Jun 2011 20:07:50 -0400
Wyatt Epp <wyatt.epp@gmail.com> wrote:

> On Thu, Jun 23, 2011 at 02:14, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > First: how do tags relate to categories? Are they independent, a
> > refinement or a replacement?
> >
> I would suggest they be a replacement because categories are just an
> overly limited subset of a proper tagging scheme.

How about packages like app-doc/pms and media-sound/pms? Shall we
prepare to have PM saying 'specify one more tag to distinguish between
the packages'?

--
Best regards,
Michał Górny
 
Old 06-24-2011, 06:51 AM
Ciaran McCreesh
 
Default Tags (Was: RFC: split up media-sound/ category)

On Thu, 23 Jun 2011 20:07:50 -0400
Wyatt Epp <wyatt.epp@gmail.com> wrote:
> On Thu, Jun 23, 2011 at 02:14, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > First: how do tags relate to categories? Are they independent, a
> > refinement or a replacement?
>
> I would suggest they be a replacement because categories are just an
> overly limited subset of a proper tagging scheme.

If you abolish categories in favour of tags, but tags don't uniquely
identify a package, how do you uniquely identify a package?

Remember that your solution has to work with overlays and with tags
being changed after a package is installed.

--
Ciaran McCreesh
 
Old 06-24-2011, 07:18 AM
Zac Medico
 
Default Tags (Was: RFC: split up media-sound/ category)

On 06/23/2011 05:07 PM, Wyatt Epp wrote:
> On Thu, Jun 23, 2011 at 02:14, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> First: how do tags relate to categories? Are they independent, a
>> refinement or a replacement?
>>
> I would suggest they be a replacement because categories are just an
> overly limited subset of a proper tagging scheme.

Since categories and tags can easily coexist, you might want to rethink
that. It's relatively easy to implement a tagging mechanism, while
(unnecessarily) ripping out the existing category framework is a big
chore that may not have any practical value.
--
Thanks,
Zac
 

Thread Tools




All times are GMT. The time now is 02:54 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org