Packaging system effort

[Joerg Sonnenberger]

On Fri, Feb 27, 2004 at 09:08:42AM -0500, Chuck Robey 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?

Having a default location is necessary to provide binary packages for all
those programs insisting on compiling hardcoded patch inside the code.
However all packages are supposed to and will be forced to be compilable
for any prefix the user chooses [well, beside OS limitations].

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

This is not a problem if you allow [and require] that multiple versions
of one package might be installed. That way each application can have
there very own dependency list, even for such problematic situations like
ABI breakage of one library version due to chaning to a dependency lib.
The later is especially probematic for C++.

> 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?

That's what the packge flags ["flavours" in OpenBSD speach] are meant for.
That way I can customize even a binary package.

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

This one is very dangerous. First of all tracking dependences of installed
applications is not easy and very limited. E.g. wether a binary is installed,
a shared library or a Python module is easy to determine, but there are
situations much more difficult. IMO the optimal solution is allow the user to
mark packages as manually installed. Therefore we don't have to add difficult
and error prone dependency detections algorithms, but KISS.

> Also, allow folks to decide that all the possible functionality of a 
> system need not be chosen to be installed.

That will done done either via flavours [for compiled-in options] or
subpackages [for plugins, documentation etc].

> OK, had my say, and I won't bother you again over it.

This is a public discussion and input is highly useful, even you don't want
to implement it :)

Joerg