From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MffMt-0008GG-Et for garchives@archives.gentoo.org; Mon, 24 Aug 2009 19:38:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 36C2CE0330; Mon, 24 Aug 2009 19:38:14 +0000 (UTC) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by pigeon.gentoo.org (Postfix) with ESMTP id 25373E0330 for ; Mon, 24 Aug 2009 19:38:14 +0000 (UTC) Received: from gw.thefreemanclan.net ([72.81.12.47]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KOW008TEBVAMYM0@vms173011.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Mon, 24 Aug 2009 14:38:03 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 6545E175A497 for ; Mon, 24 Aug 2009 15:37:57 -0400 (EDT) Message-id: <4A92EC15.1020109@gentoo.org> Date: Mon, 24 Aug 2009 15:37:57 -0400 From: Richard Freeman User-Agent: Thunderbird 2.0.0.22 (X11/20090626) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Two-level portage tree is irrelevant. References: <4A92B970.5050107@mail.ru> <20090824201111.4f7bd102@gentoo.org> In-reply-to: <20090824201111.4f7bd102@gentoo.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: 7eea9573-5092-4b0c-858f-d9f2e900d481 X-Archives-Hash: 04312477bc4f4ac7f0a5605a5d92d90e Christian Faulhammer wrote: > Hi, > > Dmitry Grigoriev : >> Jeremy Olexa already answered me in bugzilla that this is not new >> idea, but I'll submit my suggestion here anyway as a "voice of >> crowd". :) I'm just home user with about 2 years linux experience, do >> like gentoo, but with exception of this inconvenience. > > People already suggested tagging which embraces your proposal and is > more flexible. The problem is: Somehow has to do that. > I have a few thoughts on this (which are a bit scattered as they cover a few different related topics): 1. I'm not a big fan of extracting metadata from file names or paths in general (no, I don't want to rehash EAPI-in-filename here). I think that files should be named and organized in a way that makes sense, and that all metadata read by the package manager should be stored IN the file, not in the name or path. 2. Each package should have a unique identifier that doesn't change (much). Currently package category/name satisfies this. It could do so better if we separated the naming from the classification (tagging/etc) since then we wouldn't have so much renaming going on. 3. There should be other ways of finding packages that are more flexible - no restrictions on unique names, or being in a single category/etc. Tagging sounds great for this. 4. There should also be ways of storing ownership/support of packages. Again, these should be flexible, and the current xml approach works pretty well, but tagging could also be used for this (maybe with additional fields). In terms of how to maintain all the tagging, I can think of a few approaches: 1. Introduce the feature and just let devs have at it, and see what happens. Initially it won't be any worse than what we have now, and maybe it will become useful. This won't really cost anybody that much time. 2. Have some dev take the lead on it who is interested. Sure, it takes time that could be spent on other things, but I don't see volunteer effort as being a zero-sum game. For all we know the dev who takes this on was otherwise going to quit out of boredom. 3. Find ways to let non-devs contribute. This could either be in a centralized or non-centralized fashion. You could even have a tagging system where people add tags via some webpage and vote on tags others have added. If some team's ebuilds get tagged as "buggy" they can ignore it or use it to identify areas for improvement as they see fit. You are of course right that some devs at least need to build the infrastructure to make all of this work (whether in portage, or some outside application, or whatever). That doesn't mean that devs need to do all the reorganization work...