From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-65365-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id C9EB11391DB
for <garchives@archives.gentoo.org>; Sun, 23 Mar 2014 21:05:44 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D96E1E0C77;
Sun, 23 Mar 2014 21:05:34 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id D7F19E0C5E
for <gentoo-dev@lists.gentoo.org>; Sun, 23 Mar 2014 21:05:33 +0000 (UTC)
Received: from pomiot.lan (77-254-69-105.adsl.inetia.pl [77.254.69.105])
(using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: mgorny)
by smtp.gentoo.org (Postfix) with ESMTPSA id 040F433F8BC;
Sun, 23 Mar 2014 21:05:31 +0000 (UTC)
Date: Sun, 23 Mar 2014 22:05:15 +0100
From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: kumba@gentoo.org
Subject: Re: [gentoo-dev] RFC GLEP 1005: Package Tags
Message-ID: <20140323220515.22bcced5@pomiot.lan>
In-Reply-To: <532F43BF.7070405@gentoo.org>
References: <CAAr7Pr8Tjc7NDtQrUAQ7RFrT5UVyLyOfGqr0df0LV+-a-SaRtg@mail.gmail.com>
<20140323204428.58216f16@pomiot.lan>
<532F43BF.7070405@gentoo.org>
Organization: Gentoo
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
boundary="Sig_/wwWp5+x2c3TUjaMf7l4xb8V"; protocol="application/pgp-signature"
X-Archives-Salt: 83654897-9a46-4f35-8fdd-ca662aa30326
X-Archives-Hash: ac9597ac918ff18c68f957c434338f6b
--Sig_/wwWp5+x2c3TUjaMf7l4xb8V
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Dnia 2014-03-23, o godz. 16:27:43
Joshua Kinard <kumba@gentoo.org> napisa=B3(a):
> On 03/23/2014 15:44, Micha=B3 G=F3rny wrote:
> > Tags, on the other hand, are more 'live'. They place the package
> > somewhere in the 'global' tag hierarchy that can change over time.
> > I expect that people other than maintainers will be adding tags to
> > packages (and changing them), and that people will invent new tags
> > and apply them to more packages.
> >=20
> > So, first of all, your solution would mean that every commit adding
> > a new tag or changing one of the tags would modify the package
> > metadata.xml. This means a Manifest update and a ChangeLog entry (please
> > don't get into more rules for ChangeLogs now), and this means it will be
> > harder to find actually useful entries there.
> >=20
> > So we make tag updates harder, and increase time and size of rsync.
>=20
> Instead of individual <tag> lines in metadata.xml for each tag, why not a
> single <tags> line that contains a comma-delimited list of up to five tag=
s,
> whitespace optional? That should help reduce the "fluff" of the tree by
> adding this feature.
>=20
> E.g.,
>=20
> <tags>one,two,three,four,five</tags>
Either use XML, or don't use XML. Don't make this some kind of ugly
mixture of XML with non-XML.
So:
<tags>
<tag>one</tag>
<tag>two</tag>
</tags>
if we're really going for this. But I guess our DTD doesn't allow easy
definition of single <tags/> with no forced position.
> > Secondly, since tags for every package will be held in different files,
> > people will need dedicated tools to collect tags from all those files
> > and add matching tags to their own packages. Long story short, we're
> > going to have many 'duplicate' tags that will require even more commits
> > with ChangeLog entries and Manifest updates.
>=20
> If we automate the generation of a master tag index file, like
> use.desc.local, this can be avoided. emerge can simply go rummage through
> the master index for matching tag entries instead of going through the
> entire tree. Because if we wanted to sift through the entire tree, grep
> would be a far better method (compiled C and probably better text-matching
> algorithms than emerge).
And this goes pretty much backwards to what we were aiming at. We
should finally kill use.desc.local, not get inspired by the redundancy.
> > Worse than that, your GLEP doesn't even have any basic rules for naming
> > tags -- like what language form to use and, say, which character to use
> > instead of space. This sounds like the sort of things that's going to
> > make it even harder to get some consistency, especially if some
> > developers are going to follow someone else committing earlier and some
> > will follow their own rules.
>=20
> Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no
> spaces. A lot of problems are avoided if we keep tags to one-word
> descriptors only. E.g., for mail clients, they would carry both 'mail' a=
nd
> 'client' as two of their five tags. For kmail, a third tag would be 'kde'
> and Evolution would have 'gnome' instead.
I'm pretty sure you will finally hit something that goes with two
words. Protocol name or something.
> I'd also suggest that 'all' be considered a default, global tag for all
> packages, it be a reserved tag internal to emerge and other package
> managers, and not count against the number of allowed tags (meaning that
> technically, a package is allow five tags + 'all').
>=20
> As for default tags when a package does not define any, the package categ=
ory
> gets split at the hyphen and becomes two independent tags. This is
> overridden when at least one tag is defined in metadata.xml.
Will this have a real benefit? Sounds like unnecessary confusion for
a minor gain to me.
--=20
Best regards,
Micha=B3 G=F3rny
--Sig_/wwWp5+x2c3TUjaMf7l4xb8V
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQJ8BAEBCgBmBQJTL0yMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC
MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOPKAQAKFi38QRKtC7BzncK45af0R3
nrPBrg5YgO7NXs3Y7nmRBKAOPbSaWqLOK65bnLM7Ihpr+lsaCOO79Jh4ZJYNRkX7
63lN0PqSrdkQ91M4NjT9MMX/9j5GUq3sZk7XjHk9vnWoMIb51CCyE0W9aZE2jElG
VnnCNAlLocopIXg16x2THEQnov2axiZ5HtXS7lXWLkTVdk1m5JzJ6G2vXnx2/dQk
NaW/Mh+GHCArxW7H7pJDzNFwCD4cYF4MAnpGAXLidPSdWWaDRDs+CBgk2N8KjF8K
q5e5Qf8mkddHCpPUNaaMxF3Vf93Hr57tFKdLh7qrVhrEj9YDCllJ5UzA2gDzVgdy
YTRkWtiZ52OnhLtErc+TMpeQL6PuSOTsqoUvW+oY8t5ABRSPe85s8gVlJf9fa1AO
VBPtRcXcmbkWWrDfx62QfRdB5g4xfJTJqqQnPh/e84Qscgl8b/IG/QisIMuFwQCs
aaevMJVDzlKPtabj1JKUyGPKRUuMqhdXmtUyEVnVf18J8BZT2ouxELGs4QH8DTQF
wbRpz3vwER/Les+GT+g+1FF5g5pfx8Uey8FY4Jnnt+UJAjM4H71w8U2ynhfb3y1Z
vx8Mfikl2WgFP31xcN2/V3+TAzOIK21gN8fsfzaLjAd+FLaLQuvTlHnqn1KBTN3s
XKlSYulpWS2SPqgEmk2d
=jDZW
-----END PGP SIGNATURE-----
--Sig_/wwWp5+x2c3TUjaMf7l4xb8V--