From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DF3C31391DB for ; Sun, 23 Mar 2014 21:52:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0D616E0C4B; Sun, 23 Mar 2014 21:52:12 +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 E9822E0B2E for ; Sun, 23 Mar 2014 21:52:10 +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 B376D33F892; Sun, 23 Mar 2014 21:52:08 +0000 (UTC) Date: Sun, 23 Mar 2014 22:51:06 +0100 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-dev@lists.gentoo.org Cc: kumba@gentoo.org Subject: Re: [gentoo-dev] RFC GLEP 1005: Package Tags Message-ID: <20140323225106.5e199f7b@pomiot.lan> In-Reply-To: <532F54C4.7080205@gentoo.org> References: <20140323204428.58216f16@pomiot.lan> <532F43BF.7070405@gentoo.org> <20140323220515.22bcced5@pomiot.lan> <532F54C4.7080205@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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_/zzSX9Sv6Hl0bmPBBzonBoX4"; protocol="application/pgp-signature" X-Archives-Salt: e0157d31-b5bd-4d26-94de-1c61d5b837dc X-Archives-Hash: bcb0ad2e63d943a508242dc97e29d2f4 --Sig_/zzSX9Sv6Hl0bmPBBzonBoX4 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-03-23, o godz. 17:40:20 Joshua Kinard napisa=B3(a): > On 03/23/2014 17:05, Micha=B3 G=F3rny wrote: > > Dnia 2014-03-23, o godz. 16:27:43 > > Joshua Kinard napisa=B3(a): > >=20 > >> 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. > >>> > >>> 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 (ple= ase > >>> don't get into more rules for ChangeLogs now), and this means it will= be > >>> harder to find actually useful entries there. > >>> > >>> So we make tag updates harder, and increase time and size of rsync. > >> > >> Instead of individual lines in metadata.xml for each tag, why no= t a > >> single line that contains a comma-delimited list of up to five = tags, > >> whitespace optional? That should help reduce the "fluff" of the tree = by > >> adding this feature. > >> > >> E.g., > >> > >> one,two,three,four,five > >=20 > > Either use XML, or don't use XML. Don't make this some kind of ugly > > mixture of XML with non-XML. > >=20 > > So: > >=20 > > > > one > > two > > > >=20 > > if we're really going for this. But I guess our DTD doesn't allow easy > > definition of single with no forced position. >=20 > TBH, I don't like the use of XML at all. Never have and never will. I a= m a > big fan of INI-style definitions (i.e., like Samba's config). XML just > leads to a lot of unneeded fluff in what should be a really small file, > which is why I was proposing a single element instead of multiple > elements. metadata.xml is XML at the moment, so you are supposed to obey its rules, whether you like them or not. if you want to replace it with something else, feel free to try. But don't make a shitsoup mixin out of it. > >>> Secondly, since tags for every package will be held in different file= s, > >>> 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 commi= ts > >>> with ChangeLog entries and Manifest updates. > >> > >> If we automate the generation of a master tag index file, like > >> use.desc.local, this can be avoided. emerge can simply go rummage thr= ough > >> the master index for matching tag entries instead of going through the > >> entire tree. Because if we wanted to sift through the entire tree, gr= ep > >> would be a far better method (compiled C and probably better text-matc= hing > >> algorithms than emerge). > >=20 > > 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. >=20 > And what replaces it? What differentiates a global USE flag that has > purpose across multiple packages (like 'ipv6') against a flag that only > exists for a single package? Applications are supposed to read metadata.xml for local flags. That's all about it. Having an extra index file doesn't really make sense there. > >>> Worse than that, your GLEP doesn't even have any basic rules for nami= ng > >>> tags -- like what language form to use and, say, which character to u= se > >>> 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 so= me > >>> will follow their own rules. > >> > >> 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= ' and > >> 'client' as two of their five tags. For kmail, a third tag would be '= kde' > >> and Evolution would have 'gnome' instead. > >=20 > > I'm pretty sure you will finally hit something that goes with two > > words. Protocol name or something. >=20 > Perhaps, but we can fight that battle when we get there. starting off wi= th > one-word tags keeps things simple for now and that'll make it easier to > determine whether this experiment actually pans out or not. If you introduce arbitrary limitations, people will either find a way around them (which means getting even worse mess) or omit some tags. Either way, tags become less helpful. > >> 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 th= at > >> technically, a package is allow five tags + 'all'). > >> > >> As for default tags when a package does not define any, the package ca= tegory > >> gets split at the hyphen and becomes two independent tags. This is > >> overridden when at least one tag is defined in metadata.xml. > >=20 > > Will this have a real benefit? Sounds like unnecessary confusion for > > a minor gain to me. >=20 > Which? The internal 'all' tag or the use of existing category names as a > default set of tags for packages that don't have any tags defined? The 'all' tag sounds like something that would have no value. The automagic tags sound like a way to confuse people -- yesterday it had this tag, now I wanted to add a new one and the old tag disappeared! Not to mention sometimes the categories don't give really useful tags. Tags are not replacing categories, so no point in trying to bind the two together. --=20 Best regards, Micha=B3 G=F3rny --Sig_/zzSX9Sv6Hl0bmPBBzonBoX4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJTL1dKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOSHkP/2/n/NFfBGOJzsaVJQ2c+J7f QtXSgUB3qXfnMaFkocJFHewvc/IwmRxXl9WLkqJ6lFIBPZDEr+VefkD3sR/5HAhv Vf2oInoXclRaoqBz9aDv0RzXpqTYb2itSVWYE2sbwpB87ZHh634/qDucrX8IYpqB hwL8pXoiuZuoyrpQvZlya6d+MTTXYKoDwkJ/o6NjiRdxQI/f/Ev8SbGwqfLqa2CY ImuU1tljQXSDhfRSP+FIJF5LH1QbBY6GPK2U4SbP1jfJRvZTe8KIEwxIn4CaEnlG XWK3fO41K3yOomYvTJgQq4ewguarhlSJGq/VHa+5jIR4OvkDpvdBUMl57ugfzFUr LF03cgtPfAX7QdNybaRF4JX3jysGZq9zQnSDZo5bSfXGyHiNAmydnj5U3gY+A5t6 2vZB2reTd+rFucFVGm+7HCewJDYX6HSMdXzMoMGU4k+2u4TuLNWs5dTHXsvD0TVt 1fwG8Y/658/zuuN20nD6MMQcF6Z5Wt2ygs0MPcyOp6cYL8PbiGvqc6iA/Enoy01O ZbCs67jiF5DwKGfXpUWkDd41aL8WH/lf7kiQY8YlItRpl9cYDZ5eW3NuWw+/W37k EE1cl/NfX8Jrv0FDq/ur9OfzjTWKF3svSPHehNcoFiuTTn/vogBFn7F3mlngeULH lAE9NNBV+Rajq+RDb9dj =BWLm -----END PGP SIGNATURE----- --Sig_/zzSX9Sv6Hl0bmPBBzonBoX4--