Feature suggestion - install packages as noon root using apt-get

[Xen]

Daniel Balosh schreef op 23-04-2016 23:52:
> Hi,
> This is not new, still thought worth bringing this up again: the
> ability to install packages using apt-get as non root is  important.
> apt-get is wonderful, let's use it as noon root.
> 
> The perfect solution:
> 1. User can have- "non root install" privilege.
> 2. User runs- `apt-get install <package> --non-root`, and <package>
> installed to ~/bin in one beautiful click.

I agree with you but I don't know everything. I think it is feasible. 
Better would probably be that if you run apt-get as non-root, it will 
prompt you if you want to install as a regular user.

Some people extract RPM packages in their local system just fine (home 
directory).

There are certainly going to be packages that don't make sense as a user 
program or installation.

But for example Squid can be perfectly run as a user. It's just that it 
needs its own user (which could be you).

The "Snappy" thing provides a bit of a model that could be extended or 
enlivened by saying that maybe /usr/local should be accessible to 
non-admins and that your user could be a member of "staff" having write 
access to /usr/local and /var/local.

That would imply group writability but the only way I know how to 
enforce this is using ACL (access control list) using faclset. A very 
little used feature.

And not elegant in my view, but a fast way to achieve it.

Non-root installation to /usr/local/ based on membership of "staff" 
would make a lot possible already. It would introduce an intermediate 
admin that feels like "yes, this is my computer" but "I still don't need 
to mess with the core system". However, again, supposing we take Squid 
as an example, it needs a user being created. Not ultimately necessary 
(it could be your user) but practically relevant.

However for programs such as LibreOffice, or anything that may access 
system libraries but may not need to change the system, it should be 
possible from my opinion and idea.

The library path may often be hard-coded into the generated binaries of 
a compilation system, no matter how odd that is.

E.g. many programs may perhaps be impossible to move around your 
filesystem just like that.

That in itself is problematic (from any perspective of flexibility; such 
as allowing people to install programs on USB drives).

The first goal you'd need to solve or reach would be for people to agree 
that flexibility of installation is a good thing.

It should not be important whether a program is installed under / or 
some /other/directory. However many programs are not statically linked 
and require the installation of libraries in addition to the program you 
are installing. That would mean those libraries would also be added to 
this /other/directory structure. In this case, given the FHS we have, 
you do get a very large hierarchy for some, and having to cd to 
/usr/local/squid/var/log is not exactly my fun moment of life.

Linux has no provision, FHS has not really any provision for packaging 
programs into their own tree. You can do it but you might need something 
easily accessible such as /opt or /local.

Simply installing your program into ~/bin won't do it. That will create:

~/bin/squid/bin
~/bin/squid/var/log

etc.

So now you need a concept of where to put those programs to begin with. 
Supposing and indicating that you still use the FHS as is, you need a 
place where to put program installation folders including possibly their 
libraries.

This would imply that you get:

~/Programs/
~/Libraries/

as additional directories for a user home.

Otherwise the system could not really determine like that where to put 
libraries it also needs to pull in. Do you put them all beneath your 
Programs/squid/ directory? Or do you want to share them?

If a user can have his/her individual shared libraries, they need a 
hierarchy, but I hope you are not suggesting making it:

~/bin
~/lib
~/etc
~/var

That would clutter a home directory way too much.

While it is okay to put the entire FHS of a single package under e.g. 
~/Programs/squid/ you probably would not want to do that for libraries 
being drawn in through a package system. Fine if the libraries are all 
included with "squid" in this instance. But normally in a package system 
they aren't. That in itself is problematic but it is reality for now.

However supposing you did want this, technically it would be possible.

If you solve the library path problem.

That would enable people to install stuff on USB disk which I think 
should be your first priority: mobile apps.

Forget about a home directory. Focus on mobile apps.

Focus on what is called PortableApps on the Windows platform.

PortableApps are specially crafted (compiled, built, packaged) programs 
that are designed or modified to run solo.

If you really want to get this for Debian/Ubuntu, you can only do it in 
general by allowing "regular" packages to be automatically be 
transformed into "portable" ones.

This implies choosing a directory to use as the FHS root, and a fix to 
the LDPATH problem. If you want to know about the fix, which is obvious, 
go to:

http://xahlee.info/UnixResource_dir/_/ldpath.html

Here is the solution:

"Solaris 7 has a neat idea. There you can can specify a run time path 
which is also evaluated at run time. You link with an rpath of 
$ORIGIN/../lib. Here, $ORIGIN evaluates at run time to be the 
installation path of the binary. Now you can move the installation tree 
to another location entirely and everything will still work. We need 
this in other OS's!"

A relative path depending on the current location of the executable. How 
simple!!!!

The article appears to be from 2001.

So if you want this idea to work, if you want your idea to work, you 
need to implement this.