| 1 |
Dnia 2014-03-22, o godz. 15:33:27 |
| 2 |
Alec Warner <antarus@g.o> napisał(a): |
| 3 |
|
| 4 |
> https://wiki.gentoo.org/wiki/Package_Tags |
| 5 |
> |
| 6 |
> Object or forever hold your peace. |
| 7 |
|
| 8 |
Honestly, I don't think metadata.xml is a good place for it. While I |
| 9 |
like the consistency with general use of that file, I feel like it's |
| 10 |
going to make the application of tags more cumbersome, more noisy |
| 11 |
and make it harder to maintain consistency. |
| 12 |
|
| 13 |
As I see it, tags are not the same kind of package property |
| 14 |
as the description or package name. As I see it, current metadata.xml |
| 15 |
properties are somehow constant. They are usually set |
| 16 |
by the maintainer, do not change often and are strictly related only to |
| 17 |
the package. |
| 18 |
|
| 19 |
Tags, on the other hand, are more 'live'. They place the package |
| 20 |
somewhere in the 'global' tag hierarchy that can change over time. |
| 21 |
I expect that people other than maintainers will be adding tags to |
| 22 |
packages (and changing them), and that people will invent new tags |
| 23 |
and apply them to more packages. |
| 24 |
|
| 25 |
So, first of all, your solution would mean that every commit adding |
| 26 |
a new tag or changing one of the tags would modify the package |
| 27 |
metadata.xml. This means a Manifest update and a ChangeLog entry (please |
| 28 |
don't get into more rules for ChangeLogs now), and this means it will be |
| 29 |
harder to find actually useful entries there. |
| 30 |
|
| 31 |
So we make tag updates harder, and increase time and size of rsync. |
| 32 |
|
| 33 |
Secondly, since tags for every package will be held in different files, |
| 34 |
people will need dedicated tools to collect tags from all those files |
| 35 |
and add matching tags to their own packages. Long story short, we're |
| 36 |
going to have many 'duplicate' tags that will require even more commits |
| 37 |
with ChangeLog entries and Manifest updates. |
| 38 |
|
| 39 |
Worse than that, your GLEP doesn't even have any basic rules for naming |
| 40 |
tags -- like what language form to use and, say, which character to use |
| 41 |
instead of space. This sounds like the sort of things that's going to |
| 42 |
make it even harder to get some consistency, especially if some |
| 43 |
developers are going to follow someone else committing earlier and some |
| 44 |
will follow their own rules. |
| 45 |
|
| 46 |
I'd honestly prefer that -- if we should really keep tags in the tree |
| 47 |
-- to do that with a single 'metadata/tags' file or some kind of |
| 48 |
hierarchy there. Keep them outside the package directory -- bind |
| 49 |
packages to tags, rather than tags to packages. Keep all the commits |
| 50 |
in a single place without altering the ebuild work flow. |
| 51 |
|
| 52 |
-- |
| 53 |
Best regards, |
| 54 |
Michał Górny |
Archives