From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: KDE, metapackages, and monolithic packages
Date: Sun, 26 Feb 2006 03:52:27 -0700 [thread overview]
Message-ID: <pan.2006.02.26.10.52.26.601975@cox.net> (raw)
In-Reply-To: 4400B90D.3010108@gmail.com
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
next prev parent reply other threads:[~2006-02-26 10:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-25 8:32 [gentoo-dev] KDE, metapackages, and monolithic packages Mike Myers
2006-02-25 9:06 ` Diego 'Flameeyes' Pettenò
2006-02-25 18:33 ` Mike Myers
2006-02-25 18:44 ` Sebastian Bergmann
2006-02-25 18:45 ` John Myers
2006-02-25 20:07 ` Mike Myers
2006-02-25 20:15 ` Matthijs van der Vleuten
2006-02-26 10:52 ` Duncan [this message]
2006-02-26 23:05 ` [gentoo-dev] " Mike Myers
2006-02-27 0:56 ` Richard Fish
2006-02-27 10:09 ` Paul de Vrieze
2006-02-28 0:13 ` [gentoo-dev] " Duncan
2006-02-25 9:06 ` [gentoo-dev] " Petteri Räty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2006.02.26.10.52.26.601975@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox