| 1 |
On Saturday 18 September 2004 12:45 pm, Dan Armak wrote: |
| 2 |
> Doesn't that simply kmail etc. are in separate ebuilds? How are your |
| 3 |
> proposed pseudo-packages different (less costly) from regular ebuilds? |
| 4 |
|
| 5 |
Please keep in mind that the example below is only intended to serve as such. |
| 6 |
|
| 7 |
Partially separate, but not quite. What I had in mind is more in line with a |
| 8 |
piece of functionality similar to that of a symlink: Instead of manually |
| 9 |
tearing apart the individual KDE distribution packages after every revision, |
| 10 |
they could be left as-is. When a KMail installation was requested, for |
| 11 |
example, its dependencies could be calculated against the existing KDE |
| 12 |
packages and configured using DO_NOT_INSTALL to build only the files that |
| 13 |
were required for KMail and were not already merged onto the filesystem. |
| 14 |
|
| 15 |
This would add a certain degree of complexity, in that the system would be |
| 16 |
working with large collections of software in a closed environment, however |
| 17 |
it would lessen the amount of maintenance for the package maintainers, who |
| 18 |
would otherwise need to be continually breaking up software components into |
| 19 |
dedicated packages. I also suspect that Portage would need to be modified to |
| 20 |
accommodate that method of operation. |
| 21 |
|
| 22 |
|
| 23 |
> I'm sorry if I seemed dismissive. 11123 isn't the sole previous discussion |
| 24 |
> of this issue |
| 25 |
|
| 26 |
I wish I could claim that the developers and users in #kde were only being |
| 27 |
dismissive, rather than absolute, about their packaging scheme. Individual |
| 28 |
packages would save me a lot of time and effort in hacking their software to |
| 29 |
suit my workstation :) |
| 30 |
|
| 31 |
|
| 32 |
> Lack of manpower is rather Caleb's problem |
| 33 |
|
| 34 |
Thankfully. |
| 35 |
|
| 36 |
|
| 37 |
> IMHO the best way, from the maintainers' POV, would be to be able to use |
| 38 |
> perfectly ordinary separate ebuilds for KDE apps. And, this would require |
| 39 |
> something like the config cache to be viable. |
| 40 |
|
| 41 |
ccache could be quite helpful, regardless of the package that was being built; |
| 42 |
I agree that it would improve KDE compilation time, especially. What do you |
| 43 |
mean by "being viable"? I haven't had a chance to experiment with the |
| 44 |
software, though I thought it was already working reasonably well for most |
| 45 |
computer systems. |
| 46 |
|
| 47 |
|
| 48 |
-- |
| 49 |
Anthony Gorecki |
| 50 |
Ectro-Linux Foundation |
Archives