Packaging system effort

[Chuck Robey]

Enemy God wrote:

Can't find the exact piece to quote, but I think it
was Simon that didn't like that ports should be installed
in /usr/...
So what about installing them in /opt ???

Is that too much Solaris (or too little BSD) ???



       Jasse -- Installing Solaris/x86 right now, DF later...

 

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 
system.
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.