[haiku-development] Re: What for does SAT solver needed for package management?
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 19 Jun 2012 18:44:08 +0200
On 2012-06-19 at 13:13:03 [+0200], Stephan Aßmus <superstippi@xxxxxx> wrote:
> On 19.06.2012 11:50, David Given wrote:
> [...]
> > Additionally, and most importantly, fat binaries don't allow security
> > updates. Someone finds another libpng buffer overflow? On a system like
> > Debian you can just replace the libpng shared library and fix it
> > everwhere. On a fat binary system you can't fix it *ever*, because
> > you've got a zillion copies of libpng embedded everywhere, in a zillion
> > different versions, and some of the developers aren't going to update
> > their apps. (Debian explicitly forbids fat binaries for precisely this
> > reason.)
>
> Exactly, that is the whole point. I am quite tired of users still
> arguing pro application bundles because the space taken up by duplicated
> libs doesn't matter. Yes, it doesn't matter these days, but that's *not*
> the main benefit of shared libraries! And this point has been made over
> and over.
+1
And I'd like to point out that Stephan was the first one to actually use
the correct phrase for the discussed concept: it's "application bundle",
not "fat binary". A fat binary contains code for more than a single
architecture, which is a completely different thing (that we will *not*
support, BTW).
As Ingo has written, application bundles will be possible in Haiku. So, if
a developer wants to ship all the required libs with the application, s/he
can do so. If the packaging policy of the repository s/he intends to
publish the application allows bundles, is a different matter, though. I
expect that our core repositories will not allow that, while external
repositories are likely to allow it, since it makes most sense for
applications less tightly coupled with the system. In the end, the
application developer decides whether or not his/her application should
depend on external libs.
> > (To be honest, I personally think that Debian have done a pretty decent
> > job with their packaging architecture, and that it's really not worth
> > trying to solve all the problems that they've already solved. Haiku
> > could do *much* worse than just recompiling dpkg and apt and leaving it
> > at that. Most of the work will be in the packaging policies, anyway.)
While I don't agree about Haiku using apt/dpkg, I wholeheartedly second the
notion that most of the work is in the packaging policies and the
infrastructure that tries to enforce them.
> The thing is though, some people have put a lot of thought and research
> into the plan for the Haiku package management solution. And I trust
> them. I followed the discussion and everything they said made sense to
> me and they considered a lot of situations, use-cases and potential
> problems. For example, can using apt handle the problem that Haiku has
> three possible install locations for a package?
That's precisely one of the shortcomings of the traditional packaging
concepts (as implemented by dpkg & rpm): they are inflexible with respect
to where files live on disk. As a result, it's not possible to install a
package just for a single user or to install two different versions of the
same package. We can do that just because of our package-fs, and at a price
of some added complexity. Whether or not it is going to work as good as we
hope is hard to say at this point in time, but it would be boring to just
repeat what Linux does, wouldn't it?
;-P
cheers,
Oliver
Other related posts:
