On 25 June 2011 00:57, Nathan Phillip Brink <bi...@gentoo.org> wrote:
> On Wed, Jun 22, 2011 at 08:57:47PM -0400, Wyatt Epp wrote:
>> <cat>
>> <tag>media</tag>
>> <tag>video</tag>
>> <tag>kde</tag>
>> <tag>editors</tag>
>> </cat>
>
I'm strongly of the mind that by making the tag system arbitrarily
flat, you might be prematurely limiting yourself, as well as risking a
future where the "tag index" is a sea of meaningless words.
Tags in my mind, should be grouped by the sort of information they are
trying to convey, as opposed to being arbitrary and completely
un-grouped.
The present category system only has one namespace, which is more or
less "what-you-use-it-for", and if your tag system is likewise going
to take that vector as the only approach, you will ultimately end up
duplicating the category system, albeit without the present limitation
that means one package can only exist in one place.
This need not be the case, we can suggest alternative tag namespaces,
such as : The sorts of files it supports working with, the sorts of
things it can read, the sorts of things it can write.
At present, things that migrate one type of media to another, such as
pdf -> image , image -> pdf, image -> video , video -> images , etc
have to be forced to a sort of useless categorisation system.
However, if via tag data, we were able to annotate a) what can be
written and b) what can be read, this system could be leveraged to
epic proportions of win.
tag-lookup --supporting $( file ./foo );
....
Read/Write:
foobarnator - Blah blah blah
Read:
foo-bar - Blah blah
foo-bjaz - Blah blah blah
Write:
a2foo - Blah Blah
tag-lookup --verbose --supporting $( file ./foo );
....
Read/Write:
foobarnator - Blah blah blah
- reads x , y , z , foo
- writes a, b, c, foo
Read:
foo-bar - Blah blah
- reads foo
- writes text
foo-bjaz - Blah blah blah
- reads foo, bar
- writes text, mp3
Write:
a2foo - Blah Blah
-reads mp3, png, jpeg
-writes foo
As a side note, it may be beneficial to tag a package version
specifically for some of the above mentioned features. Especially if
you wish to support my "provides-binary" suggestion, because the
shipped binary may change from one version/slot to another.
I'm not sure if there's a way to provide data on a per-version level
yet in Metadata.xml, but I am assuming there's not as I don't see it
documented.
<pkgmetadata>
<versionspecific>
<slot>2</slot>
<pkgmetadata>
... normal stuff
</pkgmetadata>
</versionspecific>
<versionspecific>
<maxversion>1.0</maxversion>
<maxversion>1.999</maxversion>
<pkgmetadata>
... normal stuff
</pkgmetadata>
</versionspecific>
</pkgmetadata>
Or something similar.
--
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
