[haiku-development] Re: software organization/installation
- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 17 Feb 2009 09:59:45 +0100 CET
Rick Hansen <in_rapture@xxxxxxxxx> wrote:
...
> The package management system is HORRIBLE for
> binary BC
...
> The application developer is really the only
> one who can determine what version of a library
> works best with his application, so those
> dependencies should be his responsibility to
> provide and update them as needed, not some
> central authority.
...
> it just seems to make sense to give their install
> method serious consideration.
While package makers seem to often break out all
depenendencies there is, as far as I can see, nothing
stopping "fat packages", including the dependencies
instead of excluding them. (But of course not the
system-provided libraries.)
Maybe it would be possible to have weak/firm/hard
dependencies. But the data within a package can only
make very limited predictions of the future. The package
maker might know that library 2.x series promise to be
binary bc, and state that as an allowed upgrade path,
but this promise can be broken.
This is why I think package repositories (if they break
deps out) need separate metadata correction updates to
effectively patch incomplete/wrong dependencies. (Based
on user feedback?) Or one is locked to repository releases
published at firm intervals, like every quarter, where
each release tested extensively to have as few problems
as possible.
Such correction updates could "pin together" an already
published application package with an already published
library package. Effectively locking this version of the
application to that version of a library it depends on.
I must admitt that I don't know how this pinning should
be implemented. A naive/brute force thing might be to
just force-insert or replace a specific library version
in the apps lib subfolder, but that's not a good generic
solution. (Not everything has an app folder. Dependencies
can probably have some form other than executable->library.)
If "fat packages" can avoid these problems, with the
OS providing the most essential libraries, I think I'd
be content with that.
The level of fatness - how many dependencies to include
in the package - would be up to the package maker, but
there should be guidelines. (or repository rules)
(It would be cool to eventually have automated package
building, like *BSD's pkgsrc or ports.)
/Jonas.
- another "thinking out loud"-session
Other related posts:
