1 |
On Saturday 18 September 2004 22:09, Anthony Gorecki wrote: |
2 |
> > Which doesn't scale, because portage can't manage those dependencies. You |
3 |
> > can't depend on just one piece of kdebase (eg khtml) this way, and you |
4 |
> > can't add/remove just one piece without also recompiling all other pieces |
5 |
> > you want to keep. |
6 |
> |
7 |
> It would certainly require a fair amount of new scripting, regardless of |
8 |
> how the system was implemented. |
9 |
> |
10 |
> Regarding adding and removing packages, what prevents Portage from |
11 |
> compiling only the KMail components (and dependencies) of the kdepim |
12 |
> package, and then merging it onto the filesystem? Likewise, they could be |
13 |
> removed in a similar fashion. It seems as though the only major difference |
14 |
> is that the source files would be stored in a shared archive rather than an |
15 |
> independent archive. |
16 |
Doesn't that simply kmail etc. are in separate ebuilds? How are your proposed |
17 |
pseudo-packages different (less costly) from regular ebuilds? |
18 |
|
19 |
> |
20 |
> > This and similar solutions have been discussed to death before now, see |
21 |
> > bug #11123. |
22 |
> |
23 |
> I have, though we're still no closer to an actual solution. Bug #11123 was |
24 |
> last updated quite a while ago, and I don't believe that twelve replies |
25 |
> constitutes a heavily discussed topic. I don't mean to seem abrasive, |
26 |
> however this issue needs to be addressed, not deferred. |
27 |
I'm sorry if I seemed dismissive. 11123 isn't the sole previous discussion of |
28 |
this issue; it is itself a summary of previous and parallel discussions |
29 |
gentoo-dev etc, which is why it only has 12 replies - it wasn't used as the |
30 |
main discussion forum. It may even be that some rejected solution(s) isn't |
31 |
mentioned in. |
32 |
|
33 |
The key point of previous discussions, which is also described in 11123, is |
34 |
the paragraph about the speed of configure i quoted here previously. To me |
35 |
this always was the major stumbling block. Lack of manpower is rather Caleb's |
36 |
problem, so I guess I'll let him comment about it ;-) |
37 |
|
38 |
> At the very least, if the Gentoo community were to agree on the best way to |
39 |
> implement the KDE package segregation, regardless of the required volunteer |
40 |
> time, it would be a step in the right direction. I would certainly be |
41 |
> willing to volunteer in helping to maintain the packages if they could be |
42 |
> properly handled by Portage. |
43 |
> |
44 |
> You mentioned "enough" maintainers. Assuming that the current maintainers |
45 |
> are already strained with keeping packages up-to-date, approximately how |
46 |
> many new volunteers would be needed? |
47 |
IMHO the best way, from the maintainers' POV, would be to be able to use |
48 |
perfectly ordinary separate ebuilds for KDE apps. And, this would require |
49 |
something like the config cache to be viable. |
50 |
|
51 |
A word about my position here; I -used- to be one of the gentoo-KDE |
52 |
maintainers but left about a year ago (my sig nonwithstanding, since I didn't |
53 |
use it until now) and came back just a few days ago and straight into this |
54 |
discussion ;-) |
55 |
|
56 |
Meanwhile Caleb's been the lead (only?) maintainer, so it's all up to him, my |
57 |
opinions are just that - opinions. That said I do want to re-join the KDE |
58 |
maintainers team; it'll probably take me a couple of weeks to get up to |
59 |
speed, right now I'm still struggling with the gcc 3.4 upgrade. |
60 |
|
61 |
-- |
62 |
Dan Armak |
63 |
Gentoo Linux developer (KDE) |
64 |
Matan, Israel |
65 |
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key |
66 |
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 |