From: Richard Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: Two-level portage tree is irrelevant.
Date: Mon, 24 Aug 2009 15:37:57 -0400 [thread overview]
Message-ID: <4A92EC15.1020109@gentoo.org> (raw)
In-Reply-To: <20090824201111.4f7bd102@gentoo.org>
Christian Faulhammer wrote:
> Hi,
>
> Dmitry Grigoriev <dimgel@mail.ru>:
>> 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...
prev parent reply other threads:[~2009-08-24 19:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-24 16:01 [gentoo-dev] Two-level portage tree is irrelevant Dmitry Grigoriev
2009-08-24 16:14 ` Andrew D Kirch
2009-08-24 17:24 ` [gentoo-dev] " Duncan
2009-08-24 18:11 ` Christian Faulhammer
2009-08-24 19:37 ` Richard Freeman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A92EC15.1020109@gentoo.org \
--to=rich0@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox