On Saturday 18 September 2004 22:09, Anthony Gorecki wrote:
> > Which doesn't scale, because portage can't manage those dependencies. You
> > can't depend on just one piece of kdebase (eg khtml) this way, and you
> > can't add/remove just one piece without also recompiling all other pieces
> > you want to keep.
>
> It would certainly require a fair amount of new scripting, regardless of
> how the system was implemented.
>
> Regarding adding and removing packages, what prevents Portage from
> compiling only the KMail components (and dependencies) of the kdepim
> package, and then merging it onto the filesystem? Likewise, they could be
> removed in a similar fashion. It seems as though the only major difference
> is that the source files would be stored in a shared archive rather than an
> independent archive.
Doesn't that simply kmail etc. are in separate ebuilds? How are your proposed 
pseudo-packages different (less costly) from regular ebuilds?

>
> > This and similar solutions have been discussed to death before now, see
> > bug #11123.
>
> I have, though we're still no closer to an actual solution. Bug #11123 was
> last updated quite a while ago, and I don't believe that twelve replies
> constitutes a heavily discussed topic. I don't mean to seem abrasive,
> however this issue needs to be addressed, not deferred.
I'm sorry if I seemed dismissive. 11123 isn't the sole previous discussion of 
this issue; it is itself a summary of previous and parallel discussions 
gentoo-dev etc, which is why it only has 12 replies - it wasn't used as the 
main discussion forum. It may even be that some rejected solution(s) isn't 
mentioned in.

The key point of previous discussions, which is also described in 11123, is 
the paragraph about the speed of configure i quoted here previously. To me 
this always was the major stumbling block. Lack of manpower is rather Caleb's 
problem, so I guess I'll let him comment about it ;-)

> At the very least, if the Gentoo community were to agree on the best way to
> implement the KDE package segregation, regardless of the required volunteer
> time, it would be a step in the right direction. I would certainly be
> willing to volunteer in helping to maintain the packages if they could be
> properly handled by Portage.
>
> You mentioned "enough" maintainers. Assuming that the current maintainers
> are already strained with keeping packages up-to-date, approximately how
> many new volunteers would be needed?
IMHO the best way, from the maintainers' POV, would be to be able to use 
perfectly ordinary separate ebuilds for KDE apps. And, this would require 
something like the config cache to be viable.

A word about my position here; I -used- to be one of the gentoo-KDE 
maintainers but left about a year ago (my sig nonwithstanding, since I didn't 
use it until now) and came back just a few days ago and straight into this 
discussion ;-)

Meanwhile Caleb's been the lead (only?) maintainer, so it's all up to him, my 
opinions are just that - opinions. That said I do want to re-join the KDE 
maintainers team; it'll probably take me a couple of weeks to get up to 
speed, right now I'm still struggling with the gcc 3.4 upgrade.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951