Hi Simone, Just a quick reply for now: On Mon, Sep 29, 2003 at 17:29:45 +0200, Simone Rota wrote: [...]
[Back on topic now]
I finally managed to dedicate a machine to CLC for port building/testing. cool!
The main aims of this process are essentially two, in order of importance:
- Provide a sort of "quality test" for maintained ports: good idea
- Provide binary packages. I asked for this some time ago; while it's a bit premature to add this feature to CLC (and maybe many users/packagers don't like the idea), I will keep binary packages for personal use and eventually upload them somewhere in the net, keeping them separate from CLC. Having binary packages built on a fresh CRUX installation is something I'd probably use to create customized images for my personal use (e.g. no windowaker but blackbox ;-)).
The following is just here for completeness ;-) While I love crux' package management, I fear it might become hairy once binary packages are around; I'm certainly not afraid that you Simone will run into problems (as you know what it's all about), but if Joe User decides to check out crux and wants to install let's say evolution, pkgadd evolution#$VERSION.tar.gz will "just work", while the program won't. I assume there could be scripts to handle this, but it might be hard to forbid all users to use pkgadd directly. The joy of a system without dependencies in built packages ;-) So as a summary I think it's most important to communicate clearly that "binary packages for crux" doesn't mean "RPM-like packages for crux". I'm pretty sure we can reach this goal.
Questions time:
- A confirmation: did we establihsed that /opt ports should be listed as dependencies, didn't we? Yes we did, even though this has probably not been implemented for a large number of ports.
- This was also briefly discussed before: when a package upgrade (expecially. for libraries) introduces binary incompatibility for dependent packages, we currently don't have a way to make the user aware. In such cases, should we upgrade also the dependent packages (by just increasing release number)? Hard to say. I'm not sure what's the right solution WRT the the ideas behind CRUX' package manangement. Release change for binary incompatible is fine with me (as long as we have a good way to trigger this; e.g. the maintainer of a packages with dependent packages must inform the maintainers of the those).
Misc notes:
I don't know for sure when the "build machine" will be ready to use, probably sometime next week.
I also have no idea how long a full compilation of /contrib ports could take, if the port tree changes "too fast" respect to compilation time many benefits could be lost. (and I could introduce a compile-by-request, compile only changed ports, or similar tricks)
If anyone has further suggestions or ideas, it would be gladly accepted. If you did not consider it up to now I'd strongly recommend using ccache. Inbetween minor releases of packages (the software) or new releases of the port, the speed gain is really huge.
Looking forward to this, Best regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Biel, Switzerland http://jw.tks6.net