On Monday 17 January 2005 18:23 CET Stephen P. Becker wrote:
> Dan Armak wrote:
> > On Monday 17 January 2005 17:18, Stephen P. Becker wrote:
> >>Adding some 15mb of ebuilds to portage just for one desktop environment
> >>isn't bloat?
> >
> > Any 350 ebuilds would take that much. Nothing I can do about it. Most
> > of them don't even have function defs thanks to eclasses, so they can't
> > become any smaller.
>
> And that is my point. 350 ebuilds that do the same thing that 12 did
> before is bloat.
>
> >>Particularly when the ebuilds already support splitting
> >>themselves in a different way via an environment variable?
> >
> > They DO NOT support any such thing. The split ebuilds were made so that
> > people wouldn't have to use the horrible DO_NOT_COMPILE. It's at least
> > halfway to installing manually from source.
>
> Why is DO_NOT_COMPILE so horrible? With that, people had to track down
> which programs they didn't want and add them to that variable. With
> split ebuilds, people will have to track down which ebuilds they don't
> want, bypass the meta-ebuild that installs everything, and then either
> merge what they want one-by-one or maintain their own meta-ebuild.
I think this discussion is getting rediculous. A few points about the basic
discussion which is starting here:
1a. Splitting the CVS modules is the way to ship KDE packages recommended
by the upstream devs.
1b. Gentoo is the only (big) Distro I know which doesn't do so.
1c. Each time I talk with a KDE dev about that topic the reaction is "What,
Gentoo *still* doesn't ship split packages?"
2. The followng already includes the new split packages:
| $ find /usr/portage -type d -maxdepth 2 | wc -l
| 8939
So the KDE apps are about 3% od the portage tree. Is that much? Probably.
But in KDE there *are* many apps and I doubt there are less coming with
GNOME.
3. With DO_NOT_COMPILE you efficiently circumvent the dependency tracking
done in Portage which is a PITA and tends to bite you in the same. Been
there, done that.
And another few comments about split packages vs. small/slow arches:
1. Most of your arguments show that you actually never really tested all of
KDE. Which I can understand. But that menas that you actually just threw
a stable tag on all KDE apps while you maybe tested only 75%. That won't
change with split ebuilds, but now the untested parts of KDE are
*officially* untested what they probably always were.
2. Splitting KDE puts you in the same boat as GNOME. So KDE should handled
the same way GNOME is (whichever way that is).
3. If decompressing and compiling^Wconfiguring is really that slow on other
arches, maybe the KDE maintainer could put still keep some monolithic
ebuilds (maybe package.mask'ed) in the tree for your testing pleasure.
That shouldn't be much work for them but won't make (1) go away either.
4. If you really can't test all of KDE then I'd say don't mark stable on
MIPS etc. which isn't tested. That means that for those small arches
probably only 25% (or even only the core apps) will be officially stable.
But this is (a) probably what they are used to from Gentoo anyway and (b)
what was the true state but inofficial state of the KDE packages anyway.
Cheers,
Malte, who must admit he still hasn't tried the split packages because they
don't support Live CVS updates :)
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
--
[email protected] mailing list
