Re: keeping distros and admins off of each other's toes

Paul Jarc (Fri, Feb 06, 2004 at 02:06:48PM -0500):
> There is one issue which the traditional filesystem layout handles
> well, and which has not been explicitly addressed for slashpackage,
> AFAIR: distribution-installed packages and admin-installed packages
> are kept out of each other's way via the /usr - /usr/local split.
> Hopefully, slashpackage will reduce the need/desire for repackaging,
> but it won't go away entirely.  But in fact, we can have the same
> benefits with slashpackage (using a different mechanism, of course).
> [...]
> 
> Suppose I'm an OS distributor.  I want to include skalibs in my
> distribution. [...]
> 
> But suppose instead that I want to make more intrusive modifications.
> Maybe Laurent falls behind in fixing bugs (no offense, just an
> example), or whatever, but my users want maintenance, no matter where
> it's from.  They may even be paying me to take an interest in the code
> quality of the packages I redistribute.  So now what can I do?  I
> certainly should not distribute a modified package which is still
> called /package/prog/skalibs-0.40, and when the user updates the
> distribution, they certainly should not lose the new
> /package/prog/skalibs-0.41 that they installed themselves.  (They
> should lose neither the package version, nor their current-version
> symlink setting.)
> 
> So I put this in my distribution:
> /package/prog/skalibs -> /package/host/$DOMAIN/prog/skalibs
> /package/host/$DOMAIN/prog/skalibs -> skalibs-0.40-1
> /package/host/$DOMAIN/prog/skalibs-0.40-1 is my modified version.
> Other software still accesses skalibs via the standard path.  If the
> user installs /package/admin/execline manually, because it's not
> included in my distribution, it can still find skalibs.

Good idea.

How can a user (or an individual process) achieve similar flexiblity?
Suppose the local admin provides /package/prog/skalibs-0.40 as default.
But I want to use the new /package/prog/skalibs-0.41. How can I get
this?

Sincerly,
-- 
Stefan Karrmann