[gentoo-dev] Two-level portage tree is irrelevant.

[gentoo-dev] Two-level portage tree is irrelevant.

[Dmitry Grigoriev]

Hello everyone.

I posted an enhacement suggestion to bugzilla and was advised to discuss
it here: http://bugs.gentoo.org/show_bug.cgi?id=282491 (please read with
comments).

The idea is that package tree physical structure must correspond to
logical structure. E.g. package kde/games/tactics-and-strategy/knetwalk
instead of kde-base/knetwalk, and kde/games/all instead of manually
managed meta-package or set @kde-games (kde/all == @kde,
kde/games/arcade/all == @kde-games-arcade, ...).

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.

Best regards,
Dmitry

Re: [gentoo-dev] Two-level portage tree is irrelevant.

[Andrew D Kirch]

Dmitry Grigoriev wrote:
> Hello everyone.
>
> I posted an enhacement suggestion to bugzilla and was advised to discuss
> it here: http://bugs.gentoo.org/show_bug.cgi?id=282491 (please read with
> comments).
>
> The idea is that package tree physical structure must correspond to
> logical structure. E.g. package kde/games/tactics-and-strategy/knetwalk
> instead of kde-base/knetwalk, and kde/games/all instead of manually
> managed meta-package or set @kde-games (kde/all == @kde,
> kde/games/arcade/all == @kde-games-arcade, ...).
>
> 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.
>
> Best regards,
> Dmitry
>
>
>
>   
I don't see a problem with this per-se other than that the massive
amount of re-organization which would be required, which could otherwise
be spent on fixing bugs, adding enhancements, and other cool stuff.  I
think the price is too high in the manpower catagory.

Andrew

[gentoo-dev] Re: Two-level portage tree is irrelevant.

[Duncan]

Andrew D Kirch posted on Mon, 24 Aug 2009 12:14:56 -0400 as excerpted:

> Dmitry Grigoriev wrote:
>> http://bugs.gentoo.org/show_bug.cgi?id=282491
>>
>> The idea is that package tree physical structure must correspond to
>> logical structure. E.g. package kde/games/tactics-and-strategy/knetwalk
>> instead of kde-base/knetwalk, and kde/games/all instead of manually
>> managed meta-package or set @kde-games (kde/all == @kde,
>> kde/games/arcade/all == @kde-games-arcade, ...).
>>
> I don't see a problem with this per-se other than that the massive
> amount of re-organization which would be required, which could otherwise
> be spent on fixing bugs, adding enhancements, and other cool stuff.  I
> think the price is too high in the manpower catagory.

General observation:  In the FLOSS community it is often said (correctly) 
that for something to be done, it normally must scratch an itch that 
someone with the skills to do it has, an itch bad enough to motivate the 
dedication of the necessary time and intellectual energy.

It's thus that there are all sorts of otherwise impractical little 
projects going on, some to  eventual usability, some to eventual full 
maturity, some dying on the vine, as it were.  It's the incredible 
broadness of the community, and thus the incredible broadness of 
selection of all those little projects, that continues to drive FLOSS, 
generally far more broadly and effectively than it could ever be driven 
in an unshared or charge-to-share primarily cost/payment driven 
proprietary system.

You see this put to great effect in the firefox extensions setup.  
There's dozens of browser choices, but really only one with the 
extensibility of firefox, an extensibility that many users quickly find 
indispensable, thus making firefox itself indispensable for those users.

The same applies to some Gentoo projects.  Realistically, how many of 
those exotic archs we support, if only in -prefix or experimental form, 
would even exist at all, if they had to be cost and time justified?  But 
they are someone's hobby, Gentoo is a volunteer organization, and those 
devs have volunteered to make their hobby yet another Gentoo project.

Thus we get to the point.  I agree that it's not particularly practical 
to think about how the Gentoo tree might be better organized if we were 
to do it today.  However, if someone with the skills and the drive to 
make it so can be found, that either has that itch bad enough, or can be 
/given/ that itch bad enough, to actually /make/ it so, well then, it's 
likely to happen.  Otherwise, no, it's not, as however nice it might be 
in theory, there's always higher priority more effective ways for those 
with the skills and the access to make it happen, to spend their time.

Thus, the OP's mission, should he choose to accept it, is to either 
develop the skills and become a Gentoo developer himself, thus giving 
himself access to do it, or to effectively enough spread that itch to 
someone who has the skills and the access, thus giving them the 
motivation necessary as well.

Otherwise, I agree, it's simply very unlikely to ever happen, because the 
solution we have now is "good enough" and the cost of changing it and 
taking care of all those loose ends to make it work is high enough, that 
there are always better ways to spend that time and energy.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Two-level portage tree is irrelevant.

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

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.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Two-level portage tree is irrelevant.

[Richard Freeman]

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...