DragonFly BSD
DragonFly kernel List (threaded) for 2004-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Packaging system effort


From: Chuck Robey <chuckr@xxxxxxxxxx>
Date: Fri, 27 Feb 2004 09:08:42 -0500

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.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]