Bart Smaalders wrote: > Darren J Moffat wrote: >> Peter Tribble wrote: >>> It isn't at all clear to me that any answer other than 'use tarballs' >>> is really appropriate here. I've done quite a lot of this sort of >>> thing, and tarballs (or, more generally, a simple archive I can extract) >>> is exactly what I want. I want to try a new app *now*. I want to be >>> able to try different versions, compile it myself with different >>> options, throw the whole lot away and start over. The last thing >>> I want is any software management framework getting in the way. >> >> One reason is that for the teams producing the bits there is a cost to >> packaging them up. For some products/projects they must deliver in >> the system package format (pkgadd or rpm or whatever the system >> package format is). Having to also deliver (and constantly redeliver) >> multiple bundles costs. This is one reason to only deliver in the >> system package format and have that be installable both for >> "production use" and for "evaluation"/"development". >> >> I know of projects inside Sun that have complaints about this resource >> addition. >> > > Note that it would be not difficult to allow packages to > function as tarballs for non-priv'd users.
Which is effectively what this project is all about, right ? Non root install of packages. > Of course, privs required to make postinstall scripts, etc > run correctly won't be there... but that wouldn't work in > a tarball, either. If a postinstall script needs privilege it is either a bug in the postinstall script or it is a package that isn't appropriate for end user install (eg a device driver). So yes these things don't work in the tarball case either. -- Darren J Moffat
