1 |
Mike Myers posted <4400B90D.3010108@×××××.com>, excerpted below, on Sat, |
2 |
25 Feb 2006 14:07:41 -0600: |
3 |
|
4 |
> What do I use if I just want to re-emerge a single package with the same |
5 |
> useflags? Like if something broke or if I'm using an overlay? Like, if |
6 |
> I just wanted to reinstall noatun for instance. Is there a way to do |
7 |
> that without having to have everything else reemerged? If I use the |
8 |
> metapackage, the ebuild for any specific package is blocked by the |
9 |
> metapackage ebuilds. |
10 |
|
11 |
You don't seem to have the whole picture, yet. |
12 |
|
13 |
1) KDE packages as shipped from upstream come in big huge tarballs, |
14 |
kdelibs, kdebase, kdemultimedia, etc, each of which contains a whole bunch |
15 |
of individual libraries and applications. |
16 |
|
17 |
2) Gentoo's monolithic packages are these same huge tarballs. The |
18 |
trouble is, if there's a security issue or a minor fix in just one |
19 |
application or library, using the monolithic ebuilds means rebuilding the |
20 |
WHOLE big package, ALL of kdebase, for instance, if it's a konqueror or |
21 |
KHTML vulnerability, instead of just one or two smaller packages, as is |
22 |
the case with most other stuff. |
23 |
|
24 |
3) For this reason, Gentoo developed split ebuilds -- individual packages |
25 |
for Konqueror, konqueror-libs, kwrite, etc, instead of kdebase, likewise |
26 |
for the others, kmail, knode, kontact, the various handheld syncro |
27 |
packages, instead of kdepim, etc. In addition to the above, this also |
28 |
makes it easier to install just the single apps you want, without having |
29 |
so many other dependencies, if you for instance normally run Gnome but |
30 |
want konqueror, but don't want konsole, as you use gterm. |
31 |
|
32 |
4) Gentoo actually has three levels of KDE metapackage, as well. At |
33 |
the lowest level, corresponding directly to the individual monolithic |
34 |
packages, are the metapackages that merge all of the split packages in the |
35 |
that specific monolithic package. To merge all the split packages in |
36 |
kdebase, for example, simply emerge kdebase-meta. |
37 |
|
38 |
5) Because the monolithic kdebase includes konqueror and konsole and all |
39 |
the others, it can't be installed at the same time as the individual split |
40 |
packages, so the split packages block the monolithic package that |
41 |
includes them. Likewise, the split-package meta, kdebase-meta, that would |
42 |
merge each individual split package in kdebase, blocks the kdebase |
43 |
monolithic package. |
44 |
|
45 |
6) Above the monolithic packages on one side and the low-level |
46 |
meta-packages on the other (kdebase, monolithic, on the one side, |
47 |
kdebase-meta on the other, for example, Gentoo has metas-packages that |
48 |
combine them. kde is a virtual package that is composed of all the |
49 |
monolithic packages, kdebase, kdemultimedia, kdepim, etc. At the same |
50 |
overall level on the split ebuild side is kde-meta, which combines |
51 |
kdebase-meta, kdemultimedia-meta, kdepim-meta, etc, each of which itself |
52 |
combines multiple split packages. |
53 |
|
54 |
Thus, we have (the table works best in monospace): |
55 |
|
56 |
monolithic: split: |
57 |
kde (consists of) kde-meta (consists of) |
58 |
kdebase (has inside) kdebase-meta (consists of) |
59 |
konqueror (part of kdebase) konqueror (separate package) |
60 |
libkonqueror (part of kdebase) libkonqueror (separate package) |
61 |
konsole (part of kdebase) konsole (separate package) |
62 |
... ... |
63 |
kdepim (has inside) kdepim-meta (consists of) |
64 |
kmail (part of kdepim) kmail (separate package) |
65 |
knode (part of kdepim) knode (separate package) |
66 |
... ... |
67 |
kdemultimedia (has inside) kdemultimedia-meta (consists of) |
68 |
... ... |
69 |
etc. etc. |
70 |
|
71 |
7) If you want all of KDE, then, there are two simple ways to get it, |
72 |
emerging kde-meta, to get all the split packages, or emerging kde, to get |
73 |
all the monolithic packages. The split packages at each level block the |
74 |
monolithic packages at the same level, altho it *IS* possible to merge for |
75 |
instance kdebase (monolithic) and kdepim-meta, or kmail, with only its |
76 |
dependencies, since kdebase doesn't have any of the same packages as |
77 |
kdepim-multimedia. |
78 |
|
79 |
|
80 |
So... if you merged kde-meta, you have all the split packages. If you |
81 |
want to remerge one, just do it. You cannot, however, merge kdepim, for |
82 |
example, without unmerging kdepim-meta and all its components, since they |
83 |
are basically two different ways of packaging the exact same thing, so you |
84 |
choose one or the other. |
85 |
|
86 |
BTW, the Gentoo KDE plan is (well was, I believe still is) to only provide |
87 |
the split packages for KDE4 when it comes out, tentatively scheduled 4th |
88 |
quarter this year. The Gentoo monolithic builds likely won't be provided |
89 |
any more, thus once again simplifying things down to one packaging choice. |
90 |
There are some issues with that to clear up first, mostly having to do |
91 |
with architectures where the split KDE builds now take more than twice as |
92 |
long to build, and the arch is slow as it is so we're talking a week |
93 |
build-time instead of 3-4 days, but they are being worked on, and if all |
94 |
goes well... |
95 |
|
96 |
-- |
97 |
Duncan - List replies preferred. No HTML msgs. |
98 |
"Every nonfree program has a lord, a master -- |
99 |
and if you use the program, he is your master." Richard Stallman in |
100 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
101 |
|
102 |
|
103 |
-- |
104 |
gentoo-dev@g.o mailing list |