DragonFly kernel List (threaded) for 2004-02
Re: Packaging system effort
Enemy God wrote:
I probably should keep silent, I haven't contributed up to now, but you
*really* shouldn't force *any* base install location, because it will be
wrong for some folks. For any particular disk allocation, there are
*bound* to be some really wrong choices, which are fine and
recommendable in other cases. I know, from seeing how many other
packaging efforts *do* handle this, that it's not something that's
needed to do, so why force it in this case?
Let the user do it.
You can stop reading at this point, 'cause I want to add a rant over
dependency checking, and you should be warned you don't have to read the
rest. In my own opinion, one of the most egregious problems that most
other packaging systems impose is their broken dependency checking.
This causes 3 different forms of problems:
1) In very strict cases, where the dependency checking is done *solely*
and strictly by the use of a private database, it forces a user to be
willing to use *only* those packages supplied by the system, and only
done in those ways. It usually means that a user then cannot take any
advantage of packages that are new, until they become available by your
Can't find the exact piece to quote, but I think it
was Simon that didn't like that ports should be installed
So what about installing them in /opt ???
Is that too much Solaris (or too little BSD) ???
Jasse -- Installing Solaris/x86 right now, DF later...
2) If your package system becomes popular, like RPM is, then you get a
very severe problem of dependency lists being different for the same
application, either because one porter believes that a audio helper app
is needed, and another author doesn't agree, or because of other
philosophical differences. This causes horrible dependency traps, and
anyone who has used rpms from more than one source can tell you this.
I've been recently forced to learn Linux (an employer forced it), and
rpm dependency problems are huge.
3) Because of dependency checking, ports are often set up very
ambitiously. I will use again the example of audio: what about the
folks who have no audio cards, don['t want one, and are made to miss
applications that simply will not build without a specified dependency
on audio apps?
What I am asking is, you will make things much better for one class of
folks, if you allow one form of dependency checking to exist: I will
call that form "rational" dependency checking ... I'm horrible at
naming, so please don't read too much into it. What I'm getting at it,
the dependency checking should have a mode where the checking is done by
the actual filesystem contents, and kernel. If a dependency on a
particular library must exist, have an app that compiles a test prog,
gets and tests the symbol (or maybe just links?), and doesn't depend on
a history of your own dependency being installed. Let outside software
allow to be installed.
Also, allow folks to decide that all the possible functionality of a
system need not be chosen to be installed.
Who will benefit most? Probably, the guys who know how to fix it
themselves, us programmers. Sure would be nice to have at least one
system that doesn't try to force birth to death control on apps. If you
do this, you can easily crank up a better naming system where the name
of chosen extensions can be tacked onto the package name. It won't get
rid of outsiders ability to pick a particular binary package to install,
although it might mean a larger set of packages to build to get a full
build for one particular app.
OK, had my say, and I won't bother you again over it.