Bug 282491 – Two-level package hierarchy is irrelevant.

• Product: Portage Development
• Status: RESOLVED UPSTREAM

[Description Dmitry Grigoriev 2009-08-23 20:22:22 UTC]

Hello,

You used to pack complex package hierarchies into two-level tree, e.g. net-im/skype instead of three-level net/im/skype. Not this is only unnatural like Procrustean bed, but also extremely inconvenient for users.

E.g. now I'm exploring KDE packages and it's an impossible mess. Cannot find anything. How convenient it would be to have all KDE arcade games under kde/games/arcade/ (e.g. kde/games/arcade/kbreakout). Meta packages can be named kde/games/arcade/all (all arcade games), kde/games/all (all games) and kde/all (whole kde). Possible command-line shortcuts like `emerge kde/games` == `emerge kde/games/all`). 

But now there is kde-base/kdegames-meta and kde-base/knetwalk - try to guess whether they are related or not. Well, I could use `qsearch -a | grep kde | grep -i game` but there's no guarantee I'll get what I need. E.g. now I'm searhing for eyesapplet for KDE 4.3. No idea at all (as was before with other KDE4 stuff I gave up to find). Having good package directory hierarchy, I'd just run through kde/widgets, but currently there's no way.

So I think physical directory structure of portage tree must mirror logical structure, which requires support for arbitrary tree depth.

Best regards,
Dmitry

Reproducible: Always

Steps to Reproduce:

[Comment 1 Arfrever Frehtes Taifersar Arahesis (RETIRED) 2009-08-23 20:31:49 UTC]

Please discuss your suggestion on gentoo-dev mailing list.
http://www.gentoo.org/main/en/lists.xml

[Comment 2 Dmitry Grigoriev 2009-08-23 20:39:26 UTC]

P.S. Sets are good while they are few, but they are flat AFAIK, so you can't create too many sets without falling into mess with set names, again. I doubt you'll create @kde-games for all games and @kde-games-arcade for arcade games. And if you do... hm, I think in this example it would be much simpler to take information directly from directory structure instead of duplicating it in set descriptors. 

So _explicitly_ defined sets that currently exist would be good to group together packages from different categories. But if you'll support deep package hierarchy, then directory paths (like kde/games/arcade) may be thought of as _implicit_ sets (@kde/games/arcade). 

Something like this or so.

[Comment 3 Dmitry Grigoriev 2009-08-23 20:39:48 UTC]

Ok, I will.

[Comment 4 Jeremy Olexa (darkside) (RETIRED) 2009-08-23 20:41:37 UTC]

Try app-portage/eix

%% eix eyesapplet
* kde-base/eyesapplet
     Available versions:  (3.5)  3.5.9 3.5.10
        {arts debug elibc_FreeBSD kdeenablefinal kdehiddenvisibility xinerama}
     Homepage:            http://www.kde.org/
     Description:         kicker applet: eyes following the movement of the
mouse pointer

(It is not trivial to just change the whole portage tree. This idea is not new
by the way, it has been kicked around for years)

[Comment 5 Dmitry Grigoriev 2009-08-24 15:33:23 UTC]

I could not subscribe [e-mail], but just now succeeded subscribing [e-mail]. But will answer here once more, to Jeremy.

> * kde-base/eyesapplet
> Available versions:  (3.5)  3.5.9 3.5.10

Yeah but not 4.3. Maybe there's no such thing at all, but not sure... I know that Kubuntu 9 with KDE 4.2 has that applet.

> It is not trivial to just change the whole portage tree.

Sure. But this can be done in iterations, like refactoring. Add deeper trees support to portage utilities internals, then refine emerge (and other) CLI for convenient work with support those deeper trees, and after then reshape the tree bit by bit where appropriate, without any hurry.

[Comment 6 Alec Warner (RETIRED) 2009-08-24 20:52:14 UTC]

(In reply to comment #5)
> I could not subscribe [e-mail], but just now succeeded subscribing
> [e-mail]. But will answer here once more, to Jeremy.
> 
> > * kde-base/eyesapplet
> > Available versions:  (3.5)  3.5.9 3.5.10
> 
> Yeah but not 4.3. Maybe there's no such thing at all, but not sure... I know
> that Kubuntu 9 with KDE 4.2 has that applet.
> 
> > It is not trivial to just change the whole portage tree.
> 
> Sure. But this can be done in iterations, like refactoring. Add deeper trees
> support to portage utilities internals, then refine emerge (and other) CLI for
> convenient work with support those deeper trees, and after then reshape the
> tree bit by bit where appropriate, without any hurry.
> 

So these projects tend to not happen for a number of reasons.  The first one is that contrary to popular belief; we do not always chose the 'technically correct' path; otherwise we would have abandoned the current tree structure long ago.  Suffice to say the current structure does work fairly well for the majority of use-cases (and we have edge cases like virtual/, meta-packages, and sets).

The real problem behind this kind of work is that:
 - The cost of the work typically outweighs the advantages of the work.
 - No one wants to do the work.
 - Someone wants to do the work; but never finishes it.

This isn't just modifying the tree; but also: modifying PMS to support new on-disk formats, modifying portage, pkgcore, and paludis to support the new format.  Writing migration guides for users and developers for the new scheme.  Rewriting QA tools that depend on the existing syntax...etc.

If you want this to go forward I suggest taking a subject of the tree and redoing it; see how the subset looks in the new layout.  Provide a copy of the subset for package manager developers to consume; help supply patches to get it working.

If nothing else it may be possible to never switch to this in Gentoo-x86 (due to the high cost of migrating packages and end user shuffle) but the feature could be used in other distributions.

-A

[Comment 7 Dmitry Grigoriev 2009-08-24 21:09:56 UTC]

Alec,

Thanks for answer. I won't be able to participate because it's not my area. I take my part in open-source by working on some scala/web stuff. So forget it.

Best regards,
Dmitry