[Dramatic Prelude] fsck! I'm rewriting this long email after a blackout @ home. My notebook battery suddenly died literally seconds before the power outage and I was left staring at a black screen. The cost of a new battery for my Dell is around 240 euros. Shit. [Back on topic now] I finally managed to dedicate a machine to CLC for port building/testing. We briefly discussed the idea not so long ago in CLC or CRUX Mailing List. Basically it will periodically build and install all ports in /contrib using prt-get for dependencies and log the results. The main aims of this process are essentially two, in order of importance: - Provide a sort of "quality test" for maintained ports: it would be nice to be sure that all ports in /contrib would correctly build and install on a default "blank" CRUX setup. This could be useful for testing proper dependency listing, since it's possible to leave out some deps when building ports on a machine we daily use for "real world" tasks. - 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. Brief pseudo-code explanation of the process: ------------------------------------------------------ # Initial conditions: only /base ports installed, # with some exception: openssl/h, prt-get, ports, cvsup ports -u activate_giant_fan() activate_liquid_nitrogen_cooling() for port in /contrib: prt-get install 'prt-get quickdep port' # Here we use packages built in this session. # No need to rebuild every package log_single() for port in 'prt-get quickdep port': if port not in /base, /exceptions: prt-get remove port log_all() # html report/summary? move_packages() # move binaries to another loaction so next session # they'll be recompiled ------------------------------------------------------ Questions time: - A confirmation: did we establihsed that /opt ports should be listed as dependencies, didn't we? - 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)? Please note that even if today it's quite easy to "guess" for packages that could need a recompilation, if the port tree will eventually grow, in the future the hunting for such packages could become not-so-trivial. 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. Best regards, Simone