| 1 |
On 06/22/2011 04:58 PM, Kent Fredric wrote: |
| 2 |
> On 23 June 2011 09:46, Zac Medico <zmedico@g.o> wrote: |
| 3 |
> |
| 4 |
>> It could be implemented with a metadata.xml extension, or possibly an |
| 5 |
>> new ebuild variable. A GLEP would be a good way to propose such an |
| 6 |
>> extension. |
| 7 |
> |
| 8 |
> I'd myself see metadata.xml or ebuild variables, on their own, less |
| 9 |
> than useful. |
| 10 |
> |
| 11 |
> For me, the primary benefit of the category system is it makes it easy |
| 12 |
> to locate and install packages I wish to install, and hidden metadata |
| 13 |
> stored in the package itself would prove very unhelpful in this |
| 14 |
> regard. |
| 15 |
|
| 16 |
Of course, support would have to be integrated into search tools. |
| 17 |
|
| 18 |
> In order for this metadata to be of any use to a user, it would need |
| 19 |
> to have some way to facilitate its use, whether it be a fake generated |
| 20 |
> directory of symlinks, or a dedicated program ( like debians aptitude |
| 21 |
> ) for exploring this data in a tag-oriented way. |
| 22 |
> |
| 23 |
> ( And any solution which requires software to iterate and index the |
| 24 |
> entirety of portage to accumulate this tag data, user side, will be |
| 25 |
> considerably unfavourable in my eyes ) |
| 26 |
|
| 27 |
For example, we could extend egencache to generate an index of tags, |
| 28 |
similar to how it generates use.local.desc from all of the metadata.xml |
| 29 |
files. |
| 30 |
-- |
| 31 |
Thanks, |
| 32 |
Zac |
Archives