On Tuesday April 4, [email protected] wrote:
>
> To clarify, I'm proposing this patch for eventual mainline inclusion.
>
> It adds a simple bit of API - a symlink in /proc/pid - which makes it
> easy to build relocatable software:
>
> ./configure --prefix=/proc/self/exedir/..
>
> This is useful for a variety of purposes:
>
> * Distributing programs that are runnable from CD or USB key (useful for
> Linux magazine cover disks)
>
> * Binary packages that can be installed anywhere, for instance, to your
> home directory
>
> * Network admins can more easily place programs on network mounts
>
> I'm sure you can think of others. You can patch software to be
> relocatable today, but it's awkward and error prone. A simple patch can
> allow us to get it "for free" on any UNIX software that uses the
> idiomatic autotools build system.
>
> So .... does anybody have any objections to this? Would you like to see
> it go in? Speak now or forever hold your peace! :)
It strikes me that this is very fragile. If the application calls
anything out of /bin or /usr/bin etc passing a path name which works
for the application, it will break for the helper.
It also requires all binaries use by the application to live in the
same directory. This would be OK for some applications, but not for
everything.
It sounds to me like you want a private, inherited, name space, and
Linux provides those via CLONE_NEWNS, however you probably need root
access to make that work, which isn't ideal.
I think you'd have move luck (ab)using an environment variable.
Make
/proc/self/env_prefix
be a symlink pointing to whatever the "PREFIX" environment variable
stores.
Then you just need a little shell wrapper around the app with
something like
path=`readlink /proc/$$/fd/255`
export PREFIX=`dirname $path`
exec $PREFIX/$APPLICATION
and build the application with
./configure --prefix=/proc/self/env_prefix
I'm not saying this is a "nice" solution, but I think it is no worse
than /proc/self/exedir/, and it should be more robust.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
