[nSLUG] Unpriviledged User package Management System

George N. White III gnwiii at gmail.com
Sat May 30 11:25:40 ADT 2009


On Sat, May 30, 2009 at 9:14 AM, Hatem Nassrat <hnassrat at gmail.com> wrote:

> On Sat, May 30, 2009 at 08:09:29AM -0300, George N. White III wrote:
>> My ideal distro would not have any end user packages -- those would be managed
>> by users using multiple separate package manager systems.  Openpkg does this.
>> Some other efforts (macports might be able to do this if you avoid packages like
>> apache that need to install daemons), but I guess many sites are moving to VM's
>> for this.
>
> I would like to discuss this in more detail, so I thought starting a new
> thread would be ideal. Having un-priviledged accounts on multiple system
> my issue has always been, how to easily install software under my home
> directory, or even enduser packages.  Awesome systems like TeX, Vim,
> Python, ... (probably every single system that I know of on unix) have
> the flexibility to allow for end users to install their own packages
> that were not installed system wide.

Yes, and then you end up with some add-ons known to the package manager
and others installed by user are not.   With debian you can create
dummy packages
using 'equivs'.  I was able to use that on Ubuntu 8, but the fake
packages aren't
recognized in 9.

> Here there is really two issues,
>
>    1. installing end user packages for a system that has already been
>    installed
>
>    2. installing software that was not installed system wide
>
> I will hae to checkou openpkg, but I have not yet come accross a distro
> pkg manager that has this feature. Things like CPan, easy_install (or
> PiP) allow end users to install their own packages for Perl and Python
> respectively.

openpkg.org -- The documents are a bit sketchy.  They require you to
register to enable ftp downloads.  One registration can be used from
multiple systems.

macports is really bsd based, and in principle many of the packages
can be used on GNU/linux or unix, but I haven't tried it, and it is
mostly used with Mac OS X.  With macports you get a tree with
"Portfiles" that play a role similar to RPM's spec files.

The "port" tool lets you manage the packages.  A nice feature is
that you can install multiple versions and activate/deactivate when
project A needs version N and project B needs version N+1.

RPM has options to install in a non-system tree, but work is needed to
populate the secondary database from the system database, and there
are issues like what do do when you install a new version of some package
which is later added to the system -- ideally the package manager would
detect this and offer to remove the user version.

> As for my second item, again without having looked at openpkg yet, has
> also been a hastle for me. Compiling everything from scratch somewhat
> seems like overkill and not the easiest way to go. Its not really the
> compiling but moreso having to run a few commands to install each
> package and the same for any dependency it has. I have found a cool
> little package manager that solves this named AAP
> ( http://www.a-a-p.org ). AAP is a cross platform package manager, and
> this makes it awesome. The issue is it hasn't really picked up, so right
> now its really good at installing vim :S.

Both openpkg and macports compile packages, although openpkg creates
binary RPM's that you should be able to use on multiple systems if they
are all the same.  My interest in macports and openpkg has been more as
a way of creating my own GNU/unix (Solaris, IRIX, Mac OS X)  for better
compatibilty with GNU/linux. (In my world, unix (Mac OS X) has become the
workstation platform, while support for unix servers (IRIX64, Solaris, AIX) has
gone the way of VMS and Ultrix, so GNU/linux is the only choice for the 7/24
batch processors with fibre channel based SAN storage).

> Any thoughts, ideas, or info on package managers that work within home
> directories would help this discussion kickoff.

Issues to consider include:

1.  dependencies

many of the macports and openpkg packages rely on GNU autoconf to deal
with dependencies, and use options to configure, e.g., to choose between
system libraries and versions installed by the user.   There is a list of other
packages needed by a package, but often configure fails because you don't
have the same version of library that is installed as a "system" package on
the system where the package was originally tested, so you may not be
entirely free from the need for root's involvement

2.  switching between versions

I don't know of any other package manager that has the activation feature of
macports.


-- 
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia



More information about the nSLUG mailing list