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