[gentoo-dev] KDE, metapackages, and monolithic packages

[gentoo-dev] KDE, metapackages, and monolithic packages

[Mike Myers]

Hello!

Currently, as you all surely already know, KDE is currently handled with 
metapackages or monolithic packages.  The metapackages is very 
convenient for a more complete install of KDE, and the monolithic 
packages are better or a more modular install.  However, with the 
metapackages, it seems much more difficult than necessary to rebuild the 
KDE packages.  Like, say I wanted to add a user flag to support 
something I just added, like xinerama support.  With metapackages the 
way they are now, I would have to completely uninstall every single 
package and then reemerge the metapackage and it's dependencies.  Just 
simply reemerging the metapackage doesn't actually recompile anything.  
Also, if I wanted to add support for part of KDE, like say, alsa support 
for kdemultimedia, I would have to manually unemerge each individual 
package related to kdemultimedia and then reemerge the metapackage.

My question is;  Is there any better way to do these kinds of things 
yet?  If not, are there any plans for making this kind of process any 
easier for the users?  I really like KDE and I'm sure there are a lot of 
other people that do as well.  I can understand the reason for going to 
metapackages, but it doesn't seem to have been as smooth of a process as 
intended.  At least not in some aspects.  I am not a developer, and I 
apologize if this has already been addressed.  I haven't seen anything 
related to this issue.  The KDE howto docs seem to assume the user is 
doing an initial install and it doesn't address if part of a metapackage 
is to be reinstalled.  It also suggests metapackages over monolithic 
packages.  I'm not really sure of the reason for such a suggestion if 
making a change to the USE flags is going to be so difficult.

Maybe somebody can clear this up for me?  Again, I apologize if this has 
already been addressed.

Thanks,
Mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] KDE, metapackages, and monolithic packages

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

A part you probably mixed a bit the difference between monolithic and split 
packages...

On Saturday 25 February 2006 09:32, Mike Myers wrote:
> My question is;  Is there any better way to do these kinds of things
> yet?
man emerge -> look for --newuse

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] KDE, metapackages, and monolithic packages

[Mike Myers]

Diego 'Flameeyes' Pettenò wrote:

>A part you probably mixed a bit the difference between monolithic and split 
>packages...
>
>On Saturday 25 February 2006 09:32, Mike Myers wrote:
>  
>
>>My question is;  Is there any better way to do these kinds of things
>>yet?
>>    
>>
>man emerge -> look for --newuse
>
>  
>
Sorry, I forgot to mention that.  That flag doesn't apply to the meta 
package.

If I emerge kde-meta, and then for whatever reason want to change a 
flag, like add dvd or something, I can't simply do;

emerge --newuse kde-meta

Instead, I'd have to do;

emerge --newuse  kde

which won't work because everything that the metapackage installs blocks 
the monolithic packages.

Is there any way to just install like, certain packages if you've used 
the metapackage?  Like, if I didn't want to have to wait for everything 
to be compiled?  I'd rather just be able to compile a particular package 
instead, like say if I just wanted to add alsa support to noatun or 
something.  Then I could just emerge noatun and be done with it.  
Instead, I have to recompile everything.  That probably sounds a little 
silly, but it's just an example.

Is there an easier method?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] KDE, metapackages, and monolithic packages

[Sebastian Bergmann]

[-- Attachment #1: Type: text/plain, Size: 261 bytes --]

Mike Myers schrieb:
> emerge --newuse kde-meta

 "emerge -NDu world" is what you are looking for.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [gentoo-dev] KDE, metapackages, and monolithic packages

[John Myers]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

On Saturday 25 February 2006 10:33, Mike Myers wrote:
> emerge --newuse kde-meta
use also '--deep'.
Also, consider using 'world' as the target
Also, you don't have to unmerge packages before re-merging them.
-- 
# 
# electronerd, the electronerdian from electronerdia
#

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] KDE, metapackages, and monolithic packages

[Mike Myers]

John Myers wrote:

>On Saturday 25 February 2006 10:33, Mike Myers wrote:
>  
>
>>emerge --newuse kde-meta
>>    
>>
>use also '--deep'.
>Also, consider using 'world' as the target
>Also, you don't have to unmerge packages before re-merging them.
>  
>
What do I use if I just want to re-emerge a single package with the same 
useflags?  Like if something broke or if I'm using an overlay?  Like, if 
I just wanted to reinstall noatun for instance.  Is there a way to do 
that without having to have everything else reemerged?  If I use the 
metapackage, the ebuild for any specific package is blocked by the 
metapackage ebuilds.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] KDE, metapackages, and monolithic packages

[Matthijs van der Vleuten]

On 2/25/06, Mike Myers <fluffymikey@gmail.com> wrote:
> What do I use if I just want to re-emerge a single package with the same
> useflags?  Like if something broke or if I'm using an overlay?  Like, if
> I just wanted to reinstall noatun for instance.  Is there a way to do
> that without having to have everything else reemerged?  If I use the
> metapackage, the ebuild for any specific package is blocked by the
> metapackage ebuilds.

It's as easy as emerge --oneshot noatun.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: KDE, metapackages, and monolithic packages

[Duncan]

Mike Myers posted <4400B90D.3010108@gmail.com>, excerpted below,  on Sat,
25 Feb 2006 14:07:41 -0600:

> What do I use if I just want to re-emerge a single package with the same 
> useflags?  Like if something broke or if I'm using an overlay?  Like, if 
> I just wanted to reinstall noatun for instance.  Is there a way to do 
> that without having to have everything else reemerged?  If I use the 
> metapackage, the ebuild for any specific package is blocked by the 
> metapackage ebuilds.

You don't seem to have the whole picture, yet.

1)  KDE packages as shipped from upstream come in big huge tarballs,
kdelibs, kdebase, kdemultimedia, etc, each of which contains a whole bunch
of individual libraries and applications.

2)  Gentoo's monolithic packages are these same huge tarballs.  The
trouble is, if there's a security issue or a minor fix in just one
application or library, using the monolithic ebuilds means rebuilding the
WHOLE big package, ALL of kdebase, for instance, if it's a konqueror or
KHTML vulnerability, instead of just one or two smaller packages, as is
the case with most other stuff.

3)  For this reason, Gentoo developed split ebuilds -- individual packages
for Konqueror, konqueror-libs, kwrite, etc, instead of kdebase, likewise
for the others, kmail, knode, kontact, the various handheld syncro
packages, instead of kdepim, etc.  In addition to the above, this also
makes it  easier to install just the single apps you want, without having
so many other dependencies, if you for instance normally run Gnome but
want konqueror, but don't want konsole, as you use gterm.

4)  Gentoo actually has three levels of KDE metapackage, as well.  At
the lowest level, corresponding directly to the individual monolithic
packages, are the metapackages that merge all of the split packages in the
that specific monolithic package.  To merge all the split packages in
kdebase, for example, simply emerge kdebase-meta.

5)  Because the monolithic kdebase includes konqueror and konsole and all
the others, it can't be installed at the same time as the individual split
packages, so the split packages block the monolithic package that
includes them.  Likewise, the split-package meta, kdebase-meta, that would
merge each individual split package in kdebase, blocks the kdebase
monolithic package.

6)  Above the monolithic packages on one side  and the low-level
meta-packages on the other (kdebase, monolithic, on the one side,
kdebase-meta on the other, for example, Gentoo has metas-packages that
combine them.  kde is a virtual package that is composed of all the
monolithic packages, kdebase, kdemultimedia, kdepim, etc.  At the same
overall level on the split ebuild side is kde-meta, which combines
kdebase-meta, kdemultimedia-meta, kdepim-meta, etc, each of which itself
combines multiple split packages.

Thus, we have (the table works best in monospace):

monolithic:				split:
kde (consists of)			kde-meta (consists of)
	kdebase (has inside)			kdebase-meta (consists of)
		konqueror (part of kdebase)		konqueror (separate package)
		libkonqueror (part of kdebase)		libkonqueror (separate package)
		konsole (part of kdebase)		konsole (separate package)
		...					...
	kdepim (has inside)			kdepim-meta (consists of)
		kmail (part of kdepim)			kmail (separate package)
		knode (part of kdepim)			knode (separate package)
		...					...
	kdemultimedia (has inside)		kdemultimedia-meta (consists of)
		...					...
	etc.					etc.

7)  If you want all of KDE, then, there are two simple ways to get it,
emerging kde-meta, to get all the split packages, or emerging kde, to get
all the monolithic packages.  The split packages at each level block the
monolithic packages at the same level, altho it *IS* possible to merge for
instance kdebase (monolithic) and kdepim-meta, or kmail, with only its
dependencies, since kdebase doesn't have any of the same packages as
kdepim-multimedia.


So... if you merged kde-meta, you have all the split packages.  If you
want to remerge one, just do it.  You cannot, however, merge kdepim, for
example, without unmerging kdepim-meta and all its components, since they
are basically two different ways of packaging the exact same thing, so you
choose one or the other.

BTW, the Gentoo KDE plan is (well was, I believe still is) to only provide
the split packages for KDE4 when it comes out, tentatively scheduled 4th
quarter this year. The Gentoo monolithic builds likely won't be provided
any more, thus once again simplifying things down to one packaging choice.
There are some issues with that to clear up first, mostly having to do
with architectures where the split KDE builds now take more than twice as
long to build, and the arch is slow as it is so we're talking a week
build-time instead of 3-4 days, but they are being worked on, and if all
goes well...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: KDE, metapackages, and monolithic packages

[Mike Myers]

Duncan wrote

[deleted]

Thanks a lot for the detailed explanation.

Do you know if there's a way or going to be a way to handle the split 
ebuilds so that reemerging or unemerging a split ebuild will reemerge or 
unemerge the corresponding packages?  It seems like the ebuilds are only 
intended to make installing kde easier, which they do, but it doesn't 
make handle uninstalling or reinstalling a split ebuild very easy at 
all.  Like, if I had kde 3.4 installed and upgraded to 3.5 and no longer 
need 3.4, I can't just do 'emerge -C kde-meta-3.4', or something similar 
if it's the installed with the split metapackage. Or if I just wanted to 
remove some split ebuild, like say kdenetwork, but leave the rest, I 
couldn't do 'emerge -c kdenetwork-meta' to uninstall the related packages.

Basically, my concern is that how KDE is installed is quite easily 
handled, but uninstalling or reinstalling is not equally as easy, at 
least in some aspects.

I hope I explain myself well enough, and thanks for your response.

Mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: KDE, metapackages, and monolithic packages

[Richard Fish]

On 2/26/06, Mike Myers <fluffymikey@gmail.com> wrote:
> Do you know if there's a way or going to be a way to handle the split
> ebuilds so that reemerging or unemerging a split ebuild will reemerge or
> unemerge the corresponding packages?

Can I suggest you move this discussion to -user?  This has nothing to
do with gentoo development.  I'll be happy to explain how what you are
asking for is accomplished on -user.

-Richard

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: KDE, metapackages, and monolithic packages

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

On Monday 27 February 2006 00:05, Mike Myers wrote:
> Duncan wrote
>
> [deleted]
>
> Thanks a lot for the detailed explanation.
>
> Do you know if there's a way or going to be a way to handle the split
> ebuilds so that reemerging or unemerging a split ebuild will reemerge
> or unemerge the corresponding packages?  It seems like the ebuilds are
> only intended to make installing kde easier, which they do, but it
> doesn't make handle uninstalling or reinstalling a split ebuild very
> easy at all.  Like, if I had kde 3.4 installed and upgraded to 3.5 and
> no longer need 3.4, I can't just do 'emerge -C kde-meta-3.4', or
> something similar if it's the installed with the split metapackage. Or
> if I just wanted to remove some split ebuild, like say kdenetwork, but
> leave the rest, I couldn't do 'emerge -c kdenetwork-meta' to uninstall
> the related packages.
>
> Basically, my concern is that how KDE is installed is quite easily
> handled, but uninstalling or reinstalling is not equally as easy, at
> least in some aspects.
>
> I hope I explain myself well enough, and thanks for your response.

It is a problem that has been present in portage since the beginning. The 
problem is that portage does not do reverse dependency tracking. The idea 
should be that when kde-meta-3.4 is deleted, it finds that there is no 
package anymore that requested the kde-3.4 subpackages. And as such 
portage would delete them. Currently we can not fix this. It has to do 
with the reasons that depclean is "broken". One problem is that currently 
portage does not record which particular versions satisfy a dependency. 
As such removing packages that should not be used, may introduce problems 
with packages that have been linked against it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

[gentoo-dev] Re: Re: KDE, metapackages, and monolithic packages

[Duncan]

Mike Myers posted <44023455.3040906@gmail.com>, excerpted below,  on Sun,
26 Feb 2006 17:05:57 -0600:

> Do you know if there's a way or going to be a way to handle the split 
> ebuilds so that reemerging or unemerging a split ebuild will reemerge or 
> unemerge the corresponding packages?  It seems like the ebuilds are only 
> intended to make installing kde easier, which they do, but it doesn't 
> make handle uninstalling or reinstalling a split ebuild very easy at 
> all.

As others have said it's a technical/portage issue.

Unmerging a package always leaves dependencies  behind.  To clean those
up, emerge -NuD world (to ensure use dependencies are uptodate), emerge -p
depclean (to get a list of what it thinks is unneeded), fix anything on
that list you know to be needed (add it to world), then either unmerge
individually (as I do, even then, ensuring I haven't missed adding
something to world that I should have, verifying what each package does
and thinking about whether I actually do need it as I go) or if you
prefer, use the depclean without the -p, then, finally, do a
revdep-rebuild (first -p it, of course) to catch any dependencies that
still might have  slipped thru and need rebuilt.

Upgrading is a bit more sensitive.  However, with things like KDE
upgrades, I'll often use the --prune parameter on emerge, combined with -p
first of course.  Then again, I unmerge manually as necessary.  One other
method I've used is to do an equery list of kde packages, then grep it 
for the version I want to unmerge, to get a  list of old packages.  So an
upgrade from 3.4 to 3.5 I'd grep for 3.4.  Finally, when you've unmerged
most old KDE packages, take a look at the old /usr/kde/<ver> dir and see
what's left there, then do equery belongs <file> with what's left, to
figure out the packages they belong to.  Anything left over that doesn't
belong to a package should be deletable, or if you prefer to be safe, move
it to a backup dir for a month or so first, so you can restore it if
necessary.  Again, after unmerging stuff, a revdep-rebuild is recommended.

As others said, please move futher discussion to either user or desktop.
I don't look at user, but I'm a regular over in desktop, where KDE
questions are happily answered, as it's certainly part of desktop.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] KDE, metapackages, and monolithic packages

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

Mike Myers wrote:
> Hello!
> 
> Currently, as you all surely already know, KDE is currently handled with
> metapackages or monolithic packages.  The metapackages is very
> convenient for a more complete install of KDE, and the monolithic
> packages are better or a more modular install.  However, with the
> metapackages, it seems much more difficult than necessary to rebuild the
> KDE packages.  Like, say I wanted to add a user flag to support
> something I just added, like xinerama support.  With metapackages the
> way they are now, I would have to completely uninstall every single
> package and then reemerge the metapackage and it's dependencies.  Just
> simply reemerging the metapackage doesn't actually recompile anything. 
> Also, if I wanted to add support for part of KDE, like say, alsa support
> for kdemultimedia, I would have to manually unemerge each individual
> package related to kdemultimedia and then reemerge the metapackage.
> 
> My question is;  Is there any better way to do these kinds of things
> yet?  If not, are there any plans for making this kind of process any
> easier for the users?  I really like KDE and I'm sure there are a lot of
> other people that do as well.  I can understand the reason for going to
> metapackages, but it doesn't seem to have been as smooth of a process as
> intended.  At least not in some aspects.  I am not a developer, and I
> apologize if this has already been addressed.  I haven't seen anything
> related to this issue.  The KDE howto docs seem to assume the user is
> doing an initial install and it doesn't address if part of a metapackage
> is to be reinstalled.  It also suggests metapackages over monolithic
> packages.  I'm not really sure of the reason for such a suggestion if
> making a change to the USE flags is going to be so difficult.
> 
> Maybe somebody can clear this up for me?  Again, I apologize if this has
> already been addressed.
> 
> Thanks,
> Mike
> 

emerge --deep --newuse --pretend world

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]