[haiku-development] Re: Haiku package management system implementation (was: Haiku package manager)
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 07 Feb 2010 15:43:23 +0000
Hi there
It would be nice if you could try to reply to the specific parts by
quoting instead of this semi top-posting, as it makes it hard to follow
when not having the whole converstation in mind otherwise.
> So basically, you find signalling hooks unnecessary. Then we'll strike
> those
> from the list. There's plenty of reason to give an application package
> the
> ability to add itself to the PATH once installed, though, or to export
> libraries to other applications, etc. You've once again just
> eliminated one
> single example I made.
Having scripts executed at add/remove time isn't a bad idea in general.
The old BeOS package format did support scripts as part of the
installation process as well for example. What I wouldn't do though is
making them an integral part of the process, but merely an optional
feature. I cannot remember a single package off hand that would have
used a script or required setting PATH or library paths when installing
and I frankly don't find it a good idea to do so. As it is implemented
right now packagefs provides a single mount where apps/bins/libs would
be published in the traditional hierarchy of
"bin"/"lib"/"share"/"include"/whatever for cli tools/libs and likely
"apps" for GUI apps. This adds a single addition to PATH, much like we
currently already have "/system", "/boot/home/config" and
"/boot/common".
Pardon me, but it looks a bit like a solution searching for a problem,
considering that we've kinda managed to get everything going with this
structure so far. Check out the various optional packages as well as
most any other software you find for Haiku. They are all built based on
these structures. The better ported ones also respect things like our
find_directory() functionality to discover paths for settings and the
like. The "quicker" ports usually don't adhere to these, but they still
follow at least the base structure.
> On the porting of apps: You know as well as I that Qt now runs on
> Haiku and
> will allow for a myriad of applications to be ported. Whether this is
> what
> you want is not important;
Ok, let's drop this one right there. With that argumentation you can
justify doing anything really. What we want is what dictates what we're
going to implement. We try to influence what gets done around that by
providing sensible designs that others can make good use of without the
need of changing much/anything. If someone really tries to just throw
all this out to provide some hacked together ports then that someone
has lost interest in the Haiku philisophy anyway and it doesn't really
make sense to try to "hold them" by compromising our designs for
everyone else.
Simply put: If it doesn't matter what we want at all, then the whole
exercise of building an OS that works the way we want it is
unjustified. Move on to linux if you're convinced of that (and I
honestly mean that, not implying anything negative).
> Also, I never said that if a package depends on a .so, that only that
> .so
> would be extracted, somehow. What I said was that packages would
> depend on
> files to make the coupling between packages looser, so if someone
> wants to,
> say, replace the system's icon theme, s/he can simply do so by
> exchanging
> one package without breaking any dependencies, since the same icon
> files
> will be available. Or, if a developer wants to use debug libraries to
> debug
> his/her applications, it should be possible to do so without screwing
> up the
> system.
I understand what you're getting at here and I think this is a genuine
point. If you depend on "libz.1.0" and would depend on the "zlib"
package in the traditional package based dependency system it becomes
cumbersome to install "zlib-debug" which would also provide "libz.1.0",
because the depending packages don't necessarily understand the
difference (or the lack thereof from their point of view) between "zlib"
and "zlib-debug". I'm not sure if this isn't better solved as "package
additions"/"subpackages", a seperate type of package overlaying parts of
a "parent" because of see below.
> This method of resolving dependencies is at least as fast as normal
> named
> dependency resolution; the sole difference is that packages are called
> by
> their contents rather than by their names. It does not slow down
> dependency
> resolution at all
Except that you're going to have more individual dependency "entries"
when you need to describe each library/file. If you depend on "OpenSSL"
that's a single package to look for, while if you're going to depend on
"libcrypto.so", "libssl.so" and maybe the individual engine libraries
(moderately good example, I know)...
What I'm not sure of though is how exactly you plan to describe the
dependency of the main package content with their support files.
Considering OpenSSL alone you have a ton of stuff ending up in share,
include and ssl. Would the library "libssl.so" tehn still depend on the
"OpenSSL" package as a whole? And if so, wouldn't that limit you to
always install "OpenSSL" anyway when pulling "libssl.so", therefore
also pulling "libcrypto.so" in a compatible version and defeating the
purpose of the file based dependency resolution? I mean what if you end
up with "libcrypto.so" from one package and "libssl.so" from another?
How are you going to decide which "OpenSSL" you're going to install and
which support files you're going to pick?
If you'd add dependency entries for each single support file to
"libssl.so" I do see it as pretty quickly becoming problematic
performance wise at least. Also maintaining/creating such packages
sounds not so fun to me. I at least don't see the cross-compiling app
developer who doesn't even have a Haiku VM to go through that process
let alone adapt his build system to spit out the necessary layout/info.
> > The idea
> > behind the package filesystem in its current form was that the
> > individual parts of the package never really wind up being unpacked
> > into the actual on-disk filesystem but instead wind up being exposed
> > via the VFS. Thus uninstalling a package quite literally doesn't
> > require more than removing the package file itself since the
> > constituent parts never got littered all over the drive in the
> > first
> > place.
>
> Exactly, and how is the system I propose different in this regard?
> The
> system embraces packagefs completely. I suggest that you read through
> what
> I've written more thoroughly.
Many of your points, like automatic "install/uninstall" are inherent
with packagefs, where packages just show up in the packagefs when they
are added and vanish when they are removed. No need to actually touch
any files by running "hooks". That's all Rene tried to point out I
think.
> It seems like I'm not being taken seriously for some reason, and
> attempts
> are being made to simply dismiss what I've written.
It's not the first discussion of this kind, and you have to understand
that it can be a bit tedious to explain our views over and over again
to people who aren't necessarily familiar with Haiku concepts. I
understand where you're coming from and I can appreciate the thought
you put into combining various strongpoints of existing package
managers and coming up with own ideas. So please try to understand us
as well when we judge how far these concepts may apply to Haiku, as we
are afterall pretty familiar with how our system works. The ideal thing
would be if you could get yourself as familiar with Haiku as with the
platform you're coming from, then you can easily see what concepts may
or may not apply to Haiku.
Regards
Michael
Other related posts:
