[gentoo-dev] Split KDE packages?

[gentoo-dev] Split KDE packages?

[Jan Winhuysen]

Hello everyone!
Is there a future plan to split the kde source packages into ebuilds for 
single applications? Debian had this once, when it was on my box. I think 
this would be a good idea, but I don't have the know-how to do it...

Regards 
   Jan

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dylan Carlson]

On Monday 27 January 2003 06:42 pm, Jan Winhuysen wrote:
> Hello everyone!
> Is there a future plan to split the kde source packages into ebuilds for
> single applications? Debian had this once, when it was on my box. I
> think this would be a good idea, but I don't have the know-how to do
> it...

It's all done via Makefiles in the source distribution mostly.   Getting 
this solved is a matter of convincing some people that this issue matters 
to enough users, and in turn finding the right way to put it in.  

Cervisia is (afaik) the only thing that exists independently of any KDE 
bundle at this moment.

Please refer to the existing bug on this issue.  Please add your comments 
and CC: yourself to it.

http://bugs.gentoo.org/show_bug.cgi?id=11123

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Stephan Hermann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,



On Tuesday 28 January 2003 01:08, Dylan Carlson wrote:
> On Monday 27 January 2003 06:42 pm, Jan Winhuysen wrote:
> > Hello everyone!
> > Is there a future plan to split the kde source packages into ebuilds for
> > single applications? Debian had this once, when it was on my box. I
> > think this would be a good idea, but I don't have the know-how to do
> > it...
>
> It's all done via Makefiles in the source distribution mostly.   Getting
> this solved is a matter of convincing some people that this issue matters
> to enough users, and in turn finding the right way to put it in.
>
> Cervisia is (afaik) the only thing that exists independently of any KDE
> bundle at this moment.
>
> Please refer to the existing bug on this issue.  Please add your comments
> and CC: yourself to it.
>
> http://bugs.gentoo.org/show_bug.cgi?id=11123

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.

regards,

\sh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Nf+7V8AnusWiV6wRAr3RAKDOscWdRsT7AekHSNFpNqNseuUMUwCgxqNF
RdUp+eaNzh+5z8uXWwrhoXs=
=VFeK
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Split KDE packages?

[Riyad Kalla]

I'd have to totally agree with this.

-----Original Message-----
From: Stephan Hermann [mailto:sh@kde-coder.de] 
Sent: Monday, January 27, 2003 8:58 PM
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Split KDE packages?


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,



On Tuesday 28 January 2003 01:08, Dylan Carlson wrote:
> On Monday 27 January 2003 06:42 pm, Jan Winhuysen wrote:
> > Hello everyone!
> > Is there a future plan to split the kde source packages into ebuilds
for
> > single applications? Debian had this once, when it was on my box. I
> > think this would be a good idea, but I don't have the know-how to do
> > it...
>
> It's all done via Makefiles in the source distribution mostly.
Getting
> this solved is a matter of convincing some people that this issue
matters
> to enough users, and in turn finding the right way to put it in.
>
> Cervisia is (afaik) the only thing that exists independently of any
KDE
> bundle at this moment.
>
> Please refer to the existing bug on this issue.  Please add your
comments
> and CC: yourself to it.
>
> http://bugs.gentoo.org/show_bug.cgi?id=11123

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.

regards,

\sh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Nf+7V8AnusWiV6wRAr3RAKDOscWdRsT7AekHSNFpNqNseuUMUwCgxqNF
RdUp+eaNzh+5z8uXWwrhoXs=
=VFeK
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dylan Carlson]

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.  

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.

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.  

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.  

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

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Jan Winhuysen]

Hoi!
jepp, i think that is one important reason to split the packages. The other 
advantage (in my opinion) is that you can customize your desktop environment. 
You don't need Kooka when you don't have a scanner or KWuFTPD when you don't 
run a FTPD. The normal KDE packages bring along a lot of these "special" 
programms. One the other hand why compiling the whole KDE games package when 
you only like KTron....
I think there must be a way to do this without getting in this configure trap 
and leaving a way for user who don't want to customize their KDE.
Regards
  Jan

--
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Split KDE packages?

[Riyad Kalla]

Good point... doesn't this require the creation/maintenance of hundreds
of new ebuilds?

> -----Original Message-----
> From: Dylan Carlson [mailto:absinthe@pobox.com] 
> Sent: Tuesday, January 28, 2003 3:34 AM
> To: sh@kde-coder.de; gentoo-dev@gentoo.org
> Subject: Re: [gentoo-dev] Split KDE packages?
> 
> 
> 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.  
> 
> 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.
> 
> 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.  
> 
> 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.  
> 
> It would save a lot of people a lot of download and recompile 
> time if it's 
> between major.minor release versions.
> 
> Cheers,
> Dylan Carlson [absinthe@pobox.com]
> 
> --
> gentoo-dev@gentoo.org mailing list
> 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Marko Mikulicic]

Riyad Kalla wrote:
> Good point... doesn't this require the creation/maintenance of hundreds
> of new ebuilds?

perhaps using eclass could reduce the body of the ebuild to a standard 
template
which can be easly maintained ?

> 
> 
>>-----Original Message-----
>>From: Dylan Carlson [mailto:absinthe@pobox.com] 
>>Sent: Tuesday, January 28, 2003 3:34 AM
>>To: sh@kde-coder.de; gentoo-dev@gentoo.org
>>Subject: Re: [gentoo-dev] Split KDE packages?
>>
>>
>>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.  
>>
>>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.
>>
>>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.  
>>
>>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.  
>>
>>It would save a lot of people a lot of download and recompile 
>>time if it's 
>>between major.minor release versions.
>>
>>Cheers,
>>Dylan Carlson [absinthe@pobox.com]
>>
>>--
>>gentoo-dev@gentoo.org mailing list
>>
> 
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Jan Winhuysen]

On Tuesday 28 January 2003 14:40, Riyad Kalla wrote:
> Good point... doesn't this require the creation/maintenance of hundreds
> of new ebuilds?

Well i think this is a major problem especially the maintance and the 
management of the dependencies. Perhabs there is a way that lies between 
these both solutions. Smaller packages than the source distribution but not 
one ebuild for every little programm or libary (to reduce complexity and  
./configure time).
-Jan


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dylan Carlson]

On Tuesday 28 January 2003 09:08 am, Marko Mikulicic wrote:
> Riyad Kalla wrote:
> > Good point... doesn't this require the creation/maintenance of
> > hundreds of new ebuilds?
>
> perhaps using eclass could reduce the body of the ebuild to a standard
> template
> which can be easly maintained ?

KDE currently has it's own set of eclasses.  

laredo # ls -1 /usr/portage/eclass/kde*
/usr/portage/eclass/kde-base.eclass
/usr/portage/eclass/kde-pre.eclass
/usr/portage/eclass/kde-dist.eclass
/usr/portage/eclass/kde-source.eclass
/usr/portage/eclass/kde-functions.eclass
/usr/portage/eclass/kde.eclass
/usr/portage/eclass/kde-i18n.eclass       
/usr/portage/eclass/kde.org.eclass
/usr/portage/eclass/kde-patch.eclass

The trick (as the Gentoo devs already know) is getting around the 
'configure' time.  Take a look at Dan Armak's explanation of the problem 
in bug # 11123.  If you have some specific ideas how those eclasses could 
be improved to support a granular KDE install, that would be very welcome.

My $.02

Caching the workdir will be necessary (via some USE flag like 'kde-cache')  
unless we pursue something different as proposed in comments #2, #3 of 
that bug.  Dan's correct in saying that caching the configuration stuff is 
not very elegant.

I think the best solution is to hack the eclass to read a variable, which 
could be set in MAKE.CONF.   Something like

KDE_PACKAGES="all"
or
KDE_PACKAGES="kword kspread kmail kwrite" [...etc...]

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dylan Carlson]

On Tuesday 28 January 2003 09:32 am, Dylan Carlson wrote:
>
> I think the best solution is to hack the eclass to read a variable,
> which could be set in MAKE.CONF.   Something like
>
> KDE_PACKAGES="all"
> or
> KDE_PACKAGES="kword kspread kmail kwrite" [...etc...]
>

*cough*  I meant that as a short-term solution, but having just re-read it 
I see where it is immediately flawed.  

If you adjust KDE_PACKAGES to update just one package (say, for a given 
patch), autoclean will wipe out the old stuff... and even if you don't 
adjust anything, you still end up recompiling things that don't need 
recompiling.

It's still better than recompiling _everything_ for those of us who don't 
use but maybe 15% of the KDE desktop suite;  however, if we can't make 
this better, I'm not sure it's worth implementing.

Caching the configuration info (somehow) seems like a necessity to me.

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

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@anoncvs.kde.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@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dylan Carlson]

On Tuesday 28 January 2003 10:27 am, Stephan Hermann wrote:
>
> And that's the problem.
> No user knows, what belongs to KDE as enviroment and what does not
> belong to KDE e.g. kportage.

Not true.  Anything in the base KDE distribution is in /portage/kde-base/.

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

I'm a developer and (to use your word) "end-customer".  I want more control 
over how things gets built.   This speaks to the core of what Gentoo is 
supposed to provide.  Control over what gets built and what doesn't, and 
how.  That's one of the core goals of Gentoo.

Also, I believe that this request speaks more to the hearts of developers 
than it does end-users.  End-users don't really care as long as it fits on 
their hard drive, because they don't know any better.

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

Your opinion is noted, but I (and others) disagree.

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

Not true.  If something is critically broken, there is patch for a good 
reason.  If there hasn't been a KDE release, it just means that the those 
patches (and others) are waiting to go through their QA for a release.  

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

Again, that is not true.  It's handled by makefiles.  There is no need to 
split up the source packages.

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

The KDE stuff is handled by an eclass where this is already handled and if 
desired can be further refined.

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

Disagree.  Writing the initial ebuilds is the difficult part.  Maintaining 
them is easy.

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

That's a little arrogant, imo.

Right back at you -- if you don't have an open mind about how these 
binaries get built, maybe you should be using another system.  The point 
of a system like Gentoo is to put more control in the hands of the users 
by providing a system like Portage.  If we were not attempting to make 
this as flexible and granular as possible, I believe it would be suitable 
for some other system.  But this is Gentoo, this is why most of us are 
here.

We're not here merely to keep our machines busy compiling code.

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dan Armak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everyone,

This is my plan :-)

I understand now that so many people have requested it that splitting the 
packages (in a way that doesn't harm those who want the full packages!) is an 
important feature. I wanted to explain to everyone what my outlook on this 
is, so I'm quoting my comments from bug #11123 (including one I added just 
now):

- ------- Additional Comment #1 From Dan Armak 2002-11-29 13:46 -------
This has been discussed before. Formally if you want to call it that - on the 
mailing lists at least. 
 
There are two ways of implementing this. 
 
Under the current portage architecture, we'd need to use separate, autonomous 
ebuilds for every 'subpackage'. This however raises a problem: 
 
A kde configure script takes as much as a minute or more to run. Today when 
you emerge all of kde you run ~17 configure scripts, i.e. as much as 20 
minutes goes there (of course everything depends on the speed of the 
machine).
If all kde-base packages are split into separate subpackage ebuilds, you'll 
get hundreds of subpackages (200+). That means an extra 200 minutes -- 3.5 
hours -- added to the compilation time of all of KDE. And most people do want 
the whole of kde. This is unacceptable. 
 
There were various proposals of caching the configuration info, or sharing it 
somewhere in /var/tmp. But all that is complex, inelegant and unpleasant to 
implement and maintain. 
 
The other possibility is having a single ebuild provide real 'subpackages' any 
combination of which could be emerged by request. However there would only be 
a single workdir, so unless you deleted /var/tmp/portage in the middle of it, 
'emerge kde' would run configure a minimal amount of times. 
 
However this requires new portage features: fex. keeping in /var/db/pkg the 
info of which subpackages are installed, and recognizing a variables/use flag 
for that purpose. 
 
Someday I hope this can be done. 

- ------- Additional Comment #8 From Dan Armak 2003-01-29 08:17 -------
 
It is not a problem to make an ebuild compile a subset of all available 
subpackages. <snip>
 
Now the best solution IMHO would be to implement 'subpackages' as i described 
before. An ebuild could then divide the files it installs into a number of 
'subpackages'. If the user requested merging certain subpackages, the ebuild 
would (should) be smart enough to take only the minimal action required to 
compile those subpackages. And if the user requested everything (as in an 
ordinary emerge command), the ebuild would be smart enough not to repeat 
actions (ie not to run configure more than once). 
 
This obviously needs portage-side support and so must come after the present 
(pre-1.4-release) feature freeze ends. I'll try to add such support then, 
meanwhile I'm dealing with bugs only... 

- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+N+HnUI2RQ41fiVERAjWDAJ9+1y4m0Uaf9mWVBHu3bz+FIjYRjQCbBil/
ac43MZk6sGapo8K2REuWBBU=
=ozoD
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dylan Carlson]

On Wednesday 29 January 2003 09:15 am, Dan Armak wrote:
>
> It is not a problem to make an ebuild compile a subset of all available
> subpackages. <snip>
>
> Now the best solution IMHO would be to implement 'subpackages' as i
> described before. An ebuild could then divide the files it installs into
> a number of 'subpackages'. If the user requested merging certain
> subpackages, the ebuild would (should) be smart enough to take only the
> minimal action required to compile those subpackages. And if the user
> requested everything (as in an ordinary emerge command), the ebuild
> would be smart enough not to repeat actions (ie not to run configure
> more than once).
>

Thanks Dan.

In the event of a patch of one of the subpackages, you would still need to 
recompile all of the subpackages you want again (instead of just the one 
that has been patched).  Is that a correct assumption?

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Split KDE packages?

[Riyad Kalla]

I have read that Debian currently supports the breaking apart of KDE's
packages like this, any ideas how they manage it with apt-get?

sidenote: from what I undertsand, it takes an eternity to get things
into Debian's software repository, would this subsequently increase the
time it took to get new releases of KDE into portage?

note: I have never used debian, I am sure the above statement is
inaccurate at best, this is only a concern gathered from the forums.

> -----Original Message-----
> From: Dylan Carlson [mailto:absinthe@pobox.com] 
> Sent: Wednesday, January 29, 2003 7:30 AM
> To: danarmak@gentoo.org; gentoo-dev@gentoo.org
> Subject: Re: [gentoo-dev] Split KDE packages?
> 
> 
> On Wednesday 29 January 2003 09:15 am, Dan Armak wrote:
> >
> > It is not a problem to make an ebuild compile a subset of all 
> > available subpackages. <snip>
> >
> > Now the best solution IMHO would be to implement 'subpackages' as i 
> > described before. An ebuild could then divide the files it installs 
> > into a number of 'subpackages'. If the user requested 
> merging certain 
> > subpackages, the ebuild would (should) be smart enough to take only 
> > the minimal action required to compile those subpackages. 
> And if the 
> > user requested everything (as in an ordinary emerge command), the 
> > ebuild would be smart enough not to repeat actions (ie not to run 
> > configure more than once).
> >
> 
> Thanks Dan.
> 
> In the event of a patch of one of the subpackages, you would 
> still need to 
> recompile all of the subpackages you want again (instead of 
> just the one 
> that has been patched).  Is that a correct assumption?
> 
> Cheers,
> Dylan Carlson [absinthe@pobox.com]
> 
> --
> gentoo-dev@gentoo.org mailing list
> 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dan Armak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 29 January 2003 16:30, Dylan Carlson wrote:
> 
> Thanks Dan.
> 
> In the event of a patch of one of the subpackages, you would still need to 
> recompile all of the subpackages you want again (instead of just the one 
> that has been patched).  Is that a correct assumption?

I see the problem. There are several ways of gettig around this. One is this:

Every subpackage would have a version/revision number of its own. An ebuild 
would specify the version numbers of all the subpackages it provides. (Not in 
its filename, obviously.) When a new version's ebuild (or ebuild with a patch 
to one of the subpackages) is released, it provides a new lis of subpackage 
version numbers. If you upgrade from the old ebuild to the new one, only the 
subpackages whose version numbers changed will be emerged again, because the 
other ones are already considered merged. This situation can be simplified if 
we do not consider installed subpackages to be 'owned' (in /var/db/pkg) by a 
master package, but instead to be packages in their own right.

The paradigm would be that an ebuild provieds _one or more_ packages; the 
distinction between (master) packages and subpackages would disappear.

Now I must warn you these are all rough sketches and ideas off the top of my 
head, and I don't guarantee they'll actually be executed! After the freeze is 
over I'll discuss all this with the other Gentoo developersn and a decision 
will be made (by people with more say in Portage features than me, probably). 
But I'll try and convince people to do this (and possibly try to implement 
the portage features myself, I always wanted to do that...)

- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+N+6uUI2RQ41fiVERAnkUAJ9tBs1+Mre21Asj7vSiRXOlr9W6mgCfQ95I
7AZJylNkev7Kx5QbSyVn6VU=
=cfck
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dylan Carlson]

On Wednesday 29 January 2003 10:09 am, Dan Armak wrote:
>
> Every subpackage would have a version/revision number of its own. 
>

Sounds like a reasonable plan.

>
> Now I must warn you these are all rough sketches and ideas off the top
> of my head, and I don't guarantee they'll actually be executed! After
> the freeze is over I'll discuss all this with the other Gentoo
> developersn and a decision will be made (by people with more say in
> Portage features than me, probably). But I'll try and convince people to
> do this (and possibly try to implement the portage features myself, I
> always wanted to do that...)
>

That would be excellent.   I'd be willing to jump in, or at the very least 
test it out.   Thanks again.

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[John Nilsson]

This is somewhat off topic.

When/If this subpackage feature is designed/implemented would this be
usable for packages like busybox?

Busybox is a package that puts small version of the most common utils
,such as sh, wget, cat and similar, in one binary. You pick features in
a header file before compiling, and then it is called by "busybox
<util>" or a symlink <util> --> busybox. Now it would be great to have
this like bb-ash, bb-netcat and similar subpackages so you have a
consistent way of configuring "features" of "multiprogrampackages".
You might think that busybox has to be recompuled completley anyway so
why bother? For the sake of consistency in package management I say.

The gvim and vim situation also springs to mind.
gkrellm and its plugins... plugins in general could/shuld be
subpackages.

And E17 is an excellent candidate =)

What do you think?

/John



On Wed, 2003-01-29 at 15:15, Dan Armak wrote:

>  
> Now the best solution IMHO would be to implement 'subpackages' as i described 
> before. An ebuild could then divide the files it installs into a number of 
> 'subpackages'. If the user requested merging certain subpackages, the ebuild 
> would (should) be smart enough to take only the minimal action required to 
> compile those subpackages. And if the user requested everything (as in an 
> ordinary emerge command), the ebuild would be smart enough not to repeat 
> actions (ie not to run configure more than once). 
>  
> This obviously needs portage-side support and so must come after the present 
> (pre-1.4-release) feature freeze ends. I'll try to add such support then, 
> meanwhile I'm dealing with bugs only... 
> 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Stephan Hermann]

Hi,


On Wednesday 29 January 2003 22:24, John Nilsson wrote:
> This is somewhat off topic.
>
> When/If this subpackage feature is designed/implemented would this be
> usable for packages like busybox?

Busybox is only one application. It combines all other things (ash,ls etc.)
 in it.
There is no need to split it up.

\sh



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[John Nilsson]

pkg_postinst() {
	einfo ""
	einfo "Edit /usr/portage/sys-apps/busybox/files/Config.h and"
	einfo "re-emerge if you need to add/remove functionality in "
	einfo "BusyBox."
	einfo ""
}

I was thinking of a more elegant way of doing this.

/John


On Thu, 2003-01-30 at 10:13, Stephan Hermann wrote:
> Hi,
> 
> 
> On Wednesday 29 January 2003 22:24, John Nilsson wrote:
> > This is somewhat off topic.
> >
> > When/If this subpackage feature is designed/implemented would this be
> > usable for packages like busybox?
> 
> Busybox is only one application. It combines all other things (ash,ls etc.)
>  in it.
> There is no need to split it up.
> 
> \sh
> 
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split KDE packages?

[Dan Armak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 30 January 2003 12:25, John Nilsson wrote:
> pkg_postinst() {
> 	einfo ""
> 	einfo "Edit /usr/portage/sys-apps/busybox/files/Config.h and"
> 	einfo "re-emerge if you need to add/remove functionality in "
> 	einfo "BusyBox."
> 	einfo ""
> }
> 
> I was thinking of a more elegant way of doing this.

Better have the ebuild read a special env. variable or something. An ebuild is 
(in my plan) divided into subpackagse based on file ownership, i.e. there is 
a file->subpackage mapping, which wouldn't work with busybox since it only 
has 1 binary.

Of course this is all fluid as yet, so let's wait for the actual 
implementation (after the freeze) and then fit the busybox case to it.


- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+OSR0UI2RQ41fiVERArkNAJ46pwlZISoUOlVVll+jQVIxH1RmhQCfTkPQ
HT+IDPWBPuHHU4Zs/xBYYHk=
=Ja85
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list