Jose V Beneyto wrote:

...

Danny Rawlins wrote: [...] I'm not disagree with the split unless you can't maintain those ports (thing that never passed yet with you)

Thats a joke right :-) it wont be any harder for me to maintain Don't underestimate the effort. Splitting up the package will mean that

Hi, On Thu, May 01, 2008 at 17:46:28 +1000, Danny Rawlins wrote: people may end up with missmatched versions. Also, while it might be different in boost's case, other packages were rather hard to split cleanly, i.e. the "core" package would be simple but the only way to extract "addons" would be to build all, and then just to install the extra stuff which effectively meant a longer overall compile time for those that needed the whole package. As I said, it may work fine for boost, but Jose's concern is certainly valid in general, as the maintenance effort is outweights the gain.

and personally I would install the lot but I'm thinking about others that don't need every boost library. Does that mean that other's have complained about the compile time? I remember thinking it took long when all I wanted was to play wesnoth, but didn't really mind.

I have done a "prt-get dependent --all boost" and there is not many ports that depend on it, which is why i asked on the mailing list, in case others not in contrib rely on boost [...] I fear very few non contrib maintainers follow this list, so if you want to get feedback from them this should probably go to crux@; not that that's a guarantee for more feedback...

and would like to see it split up, personally I'm disappointed at the lack of feedback which goes to show no one seems to care what happens. So if no one disagrees I'll split it up. Now that's a conclusion I can't really understand... shouldn't you keep it the way it is if no one wants split packages? Especially since there are only few packages that would benefit from it according to dependent --all?

Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

Johannes Winkelmann wrote:

Hi again,

I just saw you already committed it, so this is just for the sake of completeness, if someone later wants to read up on splitting.

I assume you saw 'boost-regex', I thought the 'boost' port didn't have it included by reading the docs it says a number of library's need to be compiled separately. What i didn't realize is the 'bjam' build system does this for me.

On Thu, May 01, 2008 at 13:43:11 +0200, Johannes Winkelmann wrote:

...

Hi,

On Thu, May 01, 2008 at 17:46:28 +1000, Danny Rawlins wrote:

...

Jose V Beneyto wrote:

...

Danny Rawlins wrote:

[...]

...

...

I'm not disagree with the split unless you can't maintain those ports (thing that never passed yet with you)

Thats a joke right :-) it wont be any harder for me to maintain

Don't underestimate the effort. Splitting up the package will mean that people may end up with missmatched versions.

Thats up to the user to check with 'prt-get diff' and see for them selfs. I forgot to mention that in most cases, splitting a package is an incompatible change which will break programs depending on the "extra" libraries. IOW a 'sysup' will break the system, and revdep will be needed.

Spliting boost up isn't that tricky I have already figured that out or I wouldn't be thinking of doing that. And if it was the case of having to compile it all then rip out the select few files for each port that's pointless in my opinion, and I wouldn't split it up. Sure ccache would help there but still I wouldn't do something silly as that unless the goal was spitted up binary ports, but that's not what CRUX needs.

For core and opt, there's a way to notify the mailing list for such changes. I'm not sure if this is in place for the contrib repo as well, but it might be worth setting it up if it's not.

I always thought the crux-contrib was just the place to anounce important contrib port changes and stuff, and the general list was for normal CRUX chatter.

Regards, Johannes

Regards, Danny Rawlins <Romster>