[haiku-development] Re: Haiku package management system implementation (was: Haiku package manager)
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 14 Feb 2010 13:37:01 +0100
On 2010-02-07 at 18:09:35 [+0100], David Flemström
<david.flemstrom@xxxxxxxxx> wrote:
> This solution is superior to the "virtual package" version, since someone
> releasing a package doesn't have to know which virtual packages s/he
> provides via the package; the files in the package are used as "provided
> files", as-is.
Unless you extend the approach by support for version constraints, it falls
short already for very common situations, e.g. application Foo requiring
libbar.so in a version 1.x >= 1.4. The file name dependency to "libbar.so.1"
doesn't work, since that would allow also version 1.3, while a dependency to
"libbar.so.1.4" would disallow all later versions.
> E.g., let's say that an user is programming an e-mail application, and
> creates a library called "libmail.so", intending to use internally in the
> mail app. Then, however, someone else creates a modified version of that
> mail application, and can then simply list "lib/libmail.so" as a dependency
> of the extension to share some code base with the original application. The
> original author now hears of this extension, and wants to split off
> "libmail.so" in a separate package, so that users don't have to install his
> mail application just to use the modified version. This is done, and a new
> package, "libmail", now provides the library. The original modified email
> app package will then still be working, since the dependency hasn't
> disappeared, but can still be found, yet only in a different package.
I'm somewhat baffled. Are you seriously suggesting to make a package's
private libraries visible to the package manager's dependency resolution
algorithm?
> Please refer to the Google Go programming language "interface" technology to
> learn more about why a system with this philosophy is to be preferred.
Leaving aside that I'm pretty unimpressed with Go, this is not at all
comparable. On one hand you have a developer who knows what she's plugging
together -- i.e. that the class implementing an interface actually implements
it instead of just accidentally having methods with matching signatures --
while on the other hand you have a package manager whose only available
information is the names of files without any knowledge of their meaning.
E.g. in your example (ignoring that making private libraries globally visible
is a bad idea) another mail application package with a private libmail.so
would also seem to fullful the libmail.so requirement although it wouldn't be
compatible at all.
So far I haven't seen a better idea than using named
"features"/"interfaces"/"virtual packages" to specify dependencies between
packages. File names alone simply don't carry sufficient information. One
would need to extend the approach by versioning info plus some interface
identifier, which in the end just makes the file names part superfluous.
CU, Ingo
Other related posts:
