* Re: [gentoo-dev] Split KDE packages?
2003-01-28 10:34 ` Dylan Carlson
@ 2003-01-28 10:56 ` Jan Winhuysen
2003-01-28 13:40 ` Riyad Kalla
` (2 subsequent siblings)
3 siblings, 0 replies; 22+ messages in thread
From: Jan Winhuysen @ 2003-01-28 10:56 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread* RE: [gentoo-dev] Split KDE packages?
2003-01-28 10:34 ` Dylan Carlson
2003-01-28 10:56 ` Jan Winhuysen
@ 2003-01-28 13:40 ` Riyad Kalla
2003-01-28 14:08 ` Marko Mikulicic
2003-01-28 14:24 ` Jan Winhuysen
2003-01-28 15:27 ` Stephan Hermann
2003-01-29 14:15 ` Dan Armak
3 siblings, 2 replies; 22+ messages in thread
From: Riyad Kalla @ 2003-01-28 13:40 UTC (permalink / raw
To: absinthe, sh, gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-28 13:40 ` Riyad Kalla
@ 2003-01-28 14:08 ` Marko Mikulicic
2003-01-28 14:32 ` Dylan Carlson
2003-01-28 14:24 ` Jan Winhuysen
1 sibling, 1 reply; 22+ messages in thread
From: Marko Mikulicic @ 2003-01-28 14:08 UTC (permalink / raw
To: Riyad Kalla; +Cc: absinthe, sh, gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-28 14:08 ` Marko Mikulicic
@ 2003-01-28 14:32 ` Dylan Carlson
2003-01-28 14:44 ` Dylan Carlson
0 siblings, 1 reply; 22+ messages in thread
From: Dylan Carlson @ 2003-01-28 14:32 UTC (permalink / raw
To: Marko Mikulicic, Riyad Kalla; +Cc: sh, gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-28 14:32 ` Dylan Carlson
@ 2003-01-28 14:44 ` Dylan Carlson
0 siblings, 0 replies; 22+ messages in thread
From: Dylan Carlson @ 2003-01-28 14:44 UTC (permalink / raw
To: Marko Mikulicic, Riyad Kalla; +Cc: sh, gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-28 13:40 ` Riyad Kalla
2003-01-28 14:08 ` Marko Mikulicic
@ 2003-01-28 14:24 ` Jan Winhuysen
1 sibling, 0 replies; 22+ messages in thread
From: Jan Winhuysen @ 2003-01-28 14:24 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-28 10:34 ` Dylan Carlson
2003-01-28 10:56 ` Jan Winhuysen
2003-01-28 13:40 ` Riyad Kalla
@ 2003-01-28 15:27 ` Stephan Hermann
2003-01-28 16:43 ` Dylan Carlson
2003-01-29 14:15 ` Dan Armak
3 siblings, 1 reply; 22+ messages in thread
From: Stephan Hermann @ 2003-01-28 15:27 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-28 15:27 ` Stephan Hermann
@ 2003-01-28 16:43 ` Dylan Carlson
0 siblings, 0 replies; 22+ messages in thread
From: Dylan Carlson @ 2003-01-28 16:43 UTC (permalink / raw
To: sh, gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-28 10:34 ` Dylan Carlson
` (2 preceding siblings ...)
2003-01-28 15:27 ` Stephan Hermann
@ 2003-01-29 14:15 ` Dan Armak
2003-01-29 14:30 ` Dylan Carlson
2003-01-29 21:24 ` John Nilsson
3 siblings, 2 replies; 22+ messages in thread
From: Dan Armak @ 2003-01-29 14:15 UTC (permalink / raw
To: gentoo-dev
-----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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [gentoo-dev] Split KDE packages?
2003-01-29 14:15 ` Dan Armak
@ 2003-01-29 14:30 ` Dylan Carlson
2003-01-29 14:38 ` Riyad Kalla
2003-01-29 15:09 ` Dan Armak
2003-01-29 21:24 ` John Nilsson
1 sibling, 2 replies; 22+ messages in thread
From: Dylan Carlson @ 2003-01-29 14:30 UTC (permalink / raw
To: danarmak, gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [gentoo-dev] Split KDE packages?
2003-01-29 14:30 ` Dylan Carlson
@ 2003-01-29 14:38 ` Riyad Kalla
2003-01-29 15:09 ` Dan Armak
1 sibling, 0 replies; 22+ messages in thread
From: Riyad Kalla @ 2003-01-29 14:38 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-29 14:30 ` Dylan Carlson
2003-01-29 14:38 ` Riyad Kalla
@ 2003-01-29 15:09 ` Dan Armak
2003-01-29 15:34 ` Dylan Carlson
1 sibling, 1 reply; 22+ messages in thread
From: Dan Armak @ 2003-01-29 15:09 UTC (permalink / raw
To: gentoo-dev
-----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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-29 15:09 ` Dan Armak
@ 2003-01-29 15:34 ` Dylan Carlson
0 siblings, 0 replies; 22+ messages in thread
From: Dylan Carlson @ 2003-01-29 15:34 UTC (permalink / raw
To: danarmak, gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-29 14:15 ` Dan Armak
2003-01-29 14:30 ` Dylan Carlson
@ 2003-01-29 21:24 ` John Nilsson
2003-01-30 9:13 ` Stephan Hermann
1 sibling, 1 reply; 22+ messages in thread
From: John Nilsson @ 2003-01-29 21:24 UTC (permalink / raw
To: danarmak; +Cc: gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-29 21:24 ` John Nilsson
@ 2003-01-30 9:13 ` Stephan Hermann
2003-01-30 10:25 ` John Nilsson
0 siblings, 1 reply; 22+ messages in thread
From: Stephan Hermann @ 2003-01-30 9:13 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gentoo-dev] Split KDE packages?
2003-01-30 9:13 ` Stephan Hermann
@ 2003-01-30 10:25 ` John Nilsson
2003-01-30 13:11 ` Dan Armak
0 siblings, 1 reply; 22+ messages in thread
From: John Nilsson @ 2003-01-30 10:25 UTC (permalink / raw
To: sh; +Cc: gentoo-dev
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [gentoo-dev] Split KDE packages?
2003-01-30 10:25 ` John Nilsson
@ 2003-01-30 13:11 ` Dan Armak
0 siblings, 0 replies; 22+ messages in thread
From: Dan Armak @ 2003-01-30 13:11 UTC (permalink / raw
To: gentoo-dev
-----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
^ permalink raw reply [flat|nested] 22+ messages in thread