On Mon, 29 Sep 2003 18:14:09 +0200 Johannes Winkelmann <jw@tks6.net> wrote:
Hi Simone,
Hi Johannes,
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.
I can see your point and agree that the users shoul be clearly informed that pkgadd wouldn't suffice for CLC binaries. Incidentally, this is still valid for /opt packages, for example. I thought of a prt-get switch or something similar: prt-get install `prt-get quickdep kdebase` --binary the --binary option would download packages into their dirs (or pkg_dir), then proceed as usual (the binaries are up-to-date and recompilation is not needed). PS: what about a "prt-get depinst portname" command that would automate the quickdep stuff?
- 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.
So i must be prepared to see a long list of failed installations in the first log ;-)
- 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).
Good, even if I'm not sure about the maintainer's responsability (he should have a clue about dependent packages, this could require some work; anyway prt-get dependent should help a lot). It'll be fine to hear from other maintainers too about the 'fake' upgrade issue. Problems arise when new libs are not declared as binary incompatible by their developers while in fact they are: I had some issue in the past with the fox toolkit: a minor upgrade to the lib broke some app. But it could just be that I'm extremely unlucky.
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.
Unfortunately I had some issue with ccache in the past: some port (icewm, ruby if I remember well) failed to compile; disabling ccache solved the prblem.
Looking forward to this, Best regards, Johannes
Thank you very much for your reply, Regards, Simone