[haiku] Re: The state of Haiku
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Tue, 19 Jan 2016 08:37:12 +0100
Hi Simon,
Am 18/01/2016 um 16:26 schrieb Simon Taylor:
On 17 Jan 2016, at 18:08, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote: Am 17/01/2016 um 11:44 schrieb Ingo Weinhold:
You generally cannot build an automatic BeBits kind of repository
where anyone can add their packages.
Well, one could, but only when the packages don't have any
dependencies :-)
This sort of fragility is a bit of a shame - essentially it prevents
updating library packages until any packages that use them have been
built against the updated version. My understanding is the whole
“package building automation” infrastructure is intended to make
maintaining this global consistency easier, but won’t do away with
that as a requirement.
No, you misread that. Of course, you could do something like BeBits --
but it would be the very same thing as BeBits, ie. dependency hell, part 2.
Updating a package might require updating other packages. If you are not
able to update the other packages (as you would be on something like
BeBits), you'll have the choice of which package you want to break.
Something like Bebits actually could test automatically if an executable
still links, and mark packages as broken (with an e-mail to its author
with an update request), but that's not ideal either.
The best thing to solve such a thing is a broad API that covers pretty
much anything, combined with binary compatibility (ie. native apps).
Docker has an interesting approach to this, although my understanding
of exactly how it works is pretty minimal and I’ve never used it in
practice. I believe what happens is that executables run in
essentially their own union-fs. That union-fs is built by layering
specificaly-versioned “containers” on top of each other. App1 and
App2 could depend on a container with libpng-1.2.3.4 (which would
provide /lib/libpng.so or whatever), and App3 could depend on
libpng-1.4.1 (which would also appear as /lib/libpng.so in the
virtual fs for any packages that depend on it).
AFAIK, we can only provide something like that if we give the package a
different name, like libsdl vs. libsdl2 whenever they break
compatibility. That's not an ideal solution, but could work well enough,
too.
In any case, someone has to take care of this, and this is beyond
something like BeBits can handle. IOW someone needs to know if
libpng-1.4 is compatible to -1.4.5 or not, and needs to express it in
one way or another.
Bye,
Axel.
Other related posts:
