Re: [gentoo-dev] Split KDE packages?

[Stephan Hermann]

On Tuesday 28 January 2003 11:34, Dylan Carlson wrote:
> On Monday 27 January 2003 10:57 pm, Stephan Hermann wrote:
> > I don't think this is a good idea.
> > On RedHat distribution you got this foolish system (of course binary
> > packages).
> > You don't know which application is in the normal kde distribution or
> > just a plain application like whatever.
> >
> > If you see kde as one complete desktop enviroment, then you let kde as
> > is (compiling all applications in one package the same time), there
> > aren't a lot of patches for kde in the last few months, so we can live
> > with it as is.
>
> You're arguing against something I don't think you understand at all.
>
> If KDE were broken out to smaller ebuilds, there would still be a master
> ebuild to bring them all together as one bundle, so therefore users would
> not have to remember what pieces make up a complete KDE bundle.

And that's the problem.
No user knows, what belongs to KDE as enviroment and what does not belong to 
KDE e.g. kportage.
RHs build system works like "taking the complete source, configure one time, 
and call make <application>/<lib> several times, after that put the binary 
things into several packages".

Now we're speaking about Gentoo. 
In the actual issue there is a comment from gentoo-dev published:
---------------------------><-------------------------------------------------------------
Kim Nielsen replied with "The gentoo kernel is quite stable but Gentoo was 
never ment as a server distribution even though it serves just as well as 
others like Redhat or Debian. It was intedned for network/developer use.
---------------------------><-------------------------------------------------------------

So, we're talking about developer business and not "end-customer" business.

Yes, it burns cpu power and time, but if you want bleeding edge, so please, 
leave the configure/make/make install method as is.

If someone wants to build an endcustomer distribution with gentoo, so please, 
use binary tbz packages and ship them directly to the customer. 

The difference is developer/power-user seeing and end-customer seeing.

> The end result would be absolutely no different.  People who want the whole
> KDE bundle would still get the whole KDE bundle installed the same as it
> would be otherwise.
>
> What it gives us is the ability to update one small piece of KDE without
> having to update and recompile the whole thing in the event of a patch.
> And between releases there are in fact a ton of patches that go out.

And when those "patch-releases" (kde 3.0.1/3.0.2 etc.) will come out, not only 
one application is patched.
All other patches are not directly for the public.
And if someone wants those bleeding edge, he can spare space for putting a 
self compiled (without portage) version of kde in his/her homedir.


> The only reason this hasn't been done already is because there isn't any
> obvious solution to get around the increase in compile time -- which is a
> result of having ./configure run over and over for each separate ebuild.

You can't do it normally. If you do it, you have to split up the source 
packages. 

Did you ever take look on kdextragear-(1|2) ?
Why do you think there is one admin dir for automake/autoconf ?
And what happens, when the developer of kapplication8937 decide to release a 
early alpha software ? he cvs co the admin dir and his own application cvs 
dir, and put it together.
So, if you want to have split ebuilds for kde env apps, do it as I explained.



> Once that's eliminated or mitigated, the users wouldn't know any
> difference.  But I guarantee everyone would know the difference when it
> comes time to patch KDE up for inevitable serious bugs or security flaws.

Ahhhh....so, you want to have kdenetwork-kmail-3.1-patchlvl-99_2_rc7.ebuild  
and kdenetwork-knode-patchlvl-98_1_rc5.ebuild ?
How would you handle all this patch things?

It's easier to do something like this:

mkdir bloody-kde-src
cd bloody-kde-src
cvs -d :pserver:anonymous@×××××××××××.org:/home/kde co qt-copy arts kdelibs 
kdebase
and after this a cvs -d .... diff 
then cd kdebase/<application-name>/
make
make install (if it's configured)

easier then to write new ebuilds for kde patch level 666 rc9

> It would save a lot of people a lot of download and recompile time if it's
> between major.minor release versions.

if you don't have time to download and to recompile, use redhat, suse, 
mandrake,debian.

At least, if you find a system to split up kde, you can find a good solution 
to split up binutils, when a patch for "ar" is out ,-)

My 0.2€ ;)

\sh

--
gentoo-dev@g.o mailing list