Mailing List Archive

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

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

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

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

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
#

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

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

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

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

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

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

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