From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LUQro-0007b4-6B for garchives@archives.gentoo.org; Tue, 03 Feb 2009 19:23:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8A192E05CB; Tue, 3 Feb 2009 19:23:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 694D3E05CB for ; Tue, 3 Feb 2009 19:23:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0733A644D0 for ; Tue, 3 Feb 2009 19:23:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 required=5.5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvaZ6HZ4g4h7 for ; Tue, 3 Feb 2009 19:23:19 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 01F546449C for ; Tue, 3 Feb 2009 19:23:17 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LUQrY-0006ka-0o for gentoo-dev@gentoo.org; Tue, 03 Feb 2009 19:23:12 +0000 Received: from 91.85.188.176 ([91.85.188.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Feb 2009 19:23:12 +0000 Received: from slong by 91.85.188.176 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Feb 2009 19:23:12 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: new categories: Date: Tue, 03 Feb 2009 19:21:20 +0000 Message-ID: References: <84250c9c0902010932m539beba1v19fac18fde4569d9@mail.gmail.com> <200902022310.27612.reavertm@poczta.fm> <4987EDD5.8090009@gentoo.org> <200902031047.30989.george@gentoo.org> <7c612fc60902030534t3f64ef48wb0fa0968159710e8@mail.gmail.com> 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.188.176 User-Agent: KNode/0.10.9 Sender: news X-Archives-Salt: c1c9556f-b3ec-4b4d-a5a4-bad8090a8153 X-Archives-Hash: c8a0f3c47829d4516fab6ae786b1d342 Denis Dupeyron wrote: > On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov > wrote: >> Besides, in my opinion, the ability to see "what's there" in at least >> minimally categorized way without having to resort to using some special >> tools or going to some website is worht something. In this vain I was >> proposing going the opposite direction - to allow arbitrary nesting of >> categories, like going sci-math -> sci/math and deeper (then packages >> would naturally be specified by "FQEN" - fully qualified ebuild names). >> Its not like tree walker would be the most complex part of code in >> portage.. > > Actually we'd want both tags and nesting. They don't address the same > issue. > > Arbitrary nesting of categories allows better management and storing > of ebuilds. It could also allow a meta-ebuild to depend on a whole > subcategory to ease maintenance of said meta-ebuild. It's more a > developer's feature. > That sounds very similar to sets? Sorry if I'm missing something obvious, but I thought sets were used with kde4; if they are unavailable to the ebuild author, perhaps a suitably-defined extension (for in-tree sets) might be useful? The obvious advantage being that they are not tied to a specific category, ofc; could you expand a bit on 'better management and storing'? > Tags allow ebuilds to appear as being pertinent to more > (sub-)categories than just the one they're stored into. It may help > some of us locate packages they need in a better and/or faster way. > It's more of a user's feature. > Tags sound cool. I'm opposed to losing the current single flat category schema, fwtw, unless it enables something majorly-useful. It's *way* better than other distros (I am deadset against losing all categorisation) and still nice and immediate. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LUQtT-0007rV-2y for garchives@archives.gentoo.org; Tue, 03 Feb 2009 19:25:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E9AE6E06C1; Tue, 3 Feb 2009 19:25:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C8325E06C1 for ; Tue, 3 Feb 2009 19:25:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 6541664462 for ; Tue, 3 Feb 2009 19:25:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 required=5.5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rsvv7XeC98Bn for ; Tue, 3 Feb 2009 19:25:09 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 134D4644B8 for ; Tue, 3 Feb 2009 19:25:09 +0000 (UTC) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LUQtK-0006p4-Q6 for gentoo-dev@gentoo.org; Tue, 03 Feb 2009 19:25:03 +0000 Received: from 91.85.188.176 ([91.85.188.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Feb 2009 19:25:02 +0000 Received: from slong by 91.85.188.176 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Feb 2009 19:25:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: new categories: Date: Tue, 03 Feb 2009 19:22:00 +0000 Message-ID: References: <84250c9c0902010932m539beba1v19fac18fde4569d9@mail.gmail.com> <200902022310.27612.reavertm@poczta.fm> <4987EDD5.8090009@gentoo.org> <200902031047.30989.george@gentoo.org> <7c612fc60902030534t3f64ef48wb0fa0968159710e8@mail.gmail.com> 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.188.176 User-Agent: KNode/0.10.9 Sender: news X-Archives-Salt: 9cf6a053-f6bd-4d19-87df-80fbea8b7c85 X-Archives-Hash: 57c22766834b982db3b266efe596630a Message-ID: <20090203192200.F4yb71arZnELc9Mso7rXUjsTmVhNwarlxuykIoHwc1w@z> Denis Dupeyron wrote: > On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov > wrote: >> Besides, in my opinion, the ability to see "what's there" in at least >> minimally categorized way without having to resort to using some special >> tools or going to some website is worht something. In this vain I was >> proposing going the opposite direction - to allow arbitrary nesting of >> categories, like going sci-math -> sci/math and deeper (then packages >> would naturally be specified by "FQEN" - fully qualified ebuild names). >> Its not like tree walker would be the most complex part of code in >> portage.. > > Actually we'd want both tags and nesting. They don't address the same > issue. > > Arbitrary nesting of categories allows better management and storing > of ebuilds. It could also allow a meta-ebuild to depend on a whole > subcategory to ease maintenance of said meta-ebuild. It's more a > developer's feature. > That sounds very similar to sets? Sorry if I'm missing something obvious, but I thought sets were used with kde4; if they are unavailable to the ebuild author, perhaps a suitably-defined extension (for in-tree sets) might be useful? The obvious advantage being that they are not tied to a specific category, ofc; could you expand a bit on 'better management and storing'? > Tags allow ebuilds to appear as being pertinent to more > (sub-)categories than just the one they're stored into. It may help > some of us locate packages they need in a better and/or faster way. > It's more of a user's feature. > Tags sound cool. I'm opposed to losing the current single flat category schema, fwtw, unless it enables something majorly-useful. It's *way* better than other distros (I am deadset against losing all categorisation) and still nice and immediate.