On 27 June 2011 03:12, Maciej Mrozowski <reavertm@...> wrote:
>
> I see major disadvantage with this approach. It's painful to maintain.
> Imagine hundreds of different tags, with each package having at least two
> tags. You certainly don't expect anyone to be able to maintain that.
> Also those files cannot be generated since there needs to be some original
> source of tags information to generate such 'sets' from.

This problem is in my mind somewhat twofold.

There are 2 ways to approach applying a tag.

1. Opening each package and setting its tags ( package -> tags )
2. Opening a "tag" file and setting its packages ( tag -> package )

And both approaches are very handy.

1. Is useful because it makes it easy to apply a singular tag surgically.
2. Is useful because it makes it easy to apply one tag to a raft of packages.

However, if one wishes to implement something that works without
touching anything remotely part of portage itself, and one wants a
fast and easy proof of concept , number 2 is the preferable approach.
( Because you can make a basic example set of tags easily simply with
a bit of "find > file" for each tag you wish to create  )

Ultimately I think we'll see both forms emerging, long term we'll
probably edit metadata.xml, and the data will be aggregated to form a
singular fast-to-read tag index for each tag.

But we can develop the other half of the system, the "Work with an
existing tag index of sorts" /now/ and get a working proof of concept
without needing to derail ourselves bikeshedding how the portage side
of things will work.

( And I think we can expect to see tools emerge for maintaining
package tags, whether it be surgically or low-orbit-ion-cannon grade
precision )

-- 
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