| 1 |
Dan Armak said: |
| 2 |
|
| 3 |
--------------------------------------------------------------------------------------------------------------------------------------- |
| 4 |
During the last week I've been working on separating the kde-base/* packages |
| 5 |
into 'child' packages, a feature requested by some people. [snip] |
| 6 |
|
| 7 |
2. The parent package will depend on all of its children and install nothing |
| 8 |
itself. [snip] |
| 9 |
|
| 10 |
The problem is that while every 'child' package only compiles and installs the |
| 11 |
relevant files, it still needs to run the complete configure script of its |
| 12 |
parent package. In the admittedly worst-case example of kdebase, the script |
| 13 |
takes ~1.5 minutes to execute on my P3-900. kdebase has 39 child packages, so |
| 14 |
emerging kdebase with the new setup (i.e. emerging all child packages) will |
| 15 |
take about an hour longer than emerging a monolithic kdebase takes now - |
| 16 |
worse for slower computers. |
| 17 |
|
| 18 |
Most users won't accept this tradeoff of compile time for flexibility. So if |
| 19 |
you have an alternative solution, please suggest it. Otherwise there won't be |
| 20 |
any kde child packages. Speak now or remain forever silent :-) |
| 21 |
|
| 22 |
---------------------------------------------------------------------------------------------------------------------------- |
| 23 |
|
| 24 |
Unlike the previous posts I've seen, I don't want to settle for either of those two options. |
| 25 |
Since I do most of my playing with Gentoo on a Pentium 233 w/MMX, I'm definitely |
| 26 |
sensitive to the speed issue, but I also have a strong interest in being able to install just |
| 27 |
the pieces I'm interested in. |
| 28 |
|
| 29 |
All of the suggestions I have are likely to require a change of some sort to Portage, and/or |
| 30 |
a violation of the current rules. I'm still on the steep part of the learning curve with regards |
| 31 |
to Portage, so these ideas may not be practical. If they result in someone saying "No, doing |
| 32 |
abc won't work, but it gives me an idea ― if we were to do xyz, THAT |
| 33 |
would work", that's fine by me. |
| 34 |
|
| 35 |
< Update: while writing it out, I decided the other idea was completely unworkable, so I'm down |
| 36 |
to just the one. > |
| 37 |
|
| 38 |
Make the configuration portion a separate ebuild of it's own. Assuming the configuration |
| 39 |
needs to come first, have all the other packages depend on it, and look in a pre-defined spot |
| 40 |
for the output of the configure. As I understand it, this would violate one of the rules of Portage, |
| 41 |
because an ebuild script would have to mess with files in some other ebuild's directory. |
| 42 |
This could get especially tricky with sandboxing turned on. |
| 43 |
|
| 44 |
|
| 45 |
1) Allow ebuilds to share each other's files, under a "one can write, many can read" rule. You'd |
| 46 |
probably want something to indicate when an ebuild was "sticky" and not to be cleaned up |
| 47 |
until the entire emerge was finished. (Could take up a LOT of extra space, otherwise.) |
| 48 |
|
| 49 |
2) Have a holding area, owned and managed by Portage, to hold files of this nature. The file |
| 50 |
would not be in the standard ebuild working directory, nor would it be installed to the regular |
| 51 |
system. It would be specifically for cases like this where one ebuild needs to pass information |
| 52 |
to another. (It would need to automatically be part of every sandbox.) |
| 53 |
|
| 54 |
I'm assuming that the "configuration" you're talking about is the "configure" program that sets |
| 55 |
things up for make. If so, the "configure" program in the kde-configure package would be the |
| 56 |
same configure file kde-base uses now. The "configure" program in each of the child packages |
| 57 |
would be something simple like "cp /var/tmp/portage/public/kde-config.cache config.cache". |
| 58 |
|
| 59 |
This has an obvious downside in that the tarballs from the original developer have to be tweaked |
| 60 |
somewhat, but it's a fairly simple and straightforward change. |
| 61 |
|
| 62 |
I think that in general, the ability of one ebuild to depend on another "on-the-fly" (i.e. the first ebuild |
| 63 |
does not have to be installed to production locations) would benefit Portage. |
| 64 |
|
| 65 |
Like I said, I have a strong interest in seeing this problem solved effectively. If I obviously |
| 66 |
misunderstand some portion of Portage, educate me and I'll see what else I can come up with. |
| 67 |
(I'm also willing to help script things as long as you're talking about bash. Python looks like a |
| 68 |
fairly easy language, but I'm not even slightly competent in it.) |
| 69 |
|
| 70 |
Hope this helps, |
| 71 |
|
| 72 |
Charles Lacour |
Archives