Re: Proposal: an addition to glib for getting the absolute path of the current binary.

[Enrico Weigelt <weigelt metux de>]

* Hongli Lai <h lai chello nl> [2004-04-13 01:00:49 +0200]:

<snip>
> Have you ever considered average desktop users? You know the kind of 
> people the GNOME project is targeting? Those people don't have compile 
> farms. They don't want to compile software - they shouldn't have to 
> compile software.

1. They can use another compile farm somewhere on the net
   (I'm currently setting up one ...)

2. Those end-users should either let an admin do this work or use a 
   end-user-targetted distro and should never play around with such 
   details of package installing.
   
<snip>
> Recompilation just to make the software being able to run in your home 
> folder is not acceptable for people like my dad. 
Then Your dad should use an end-user-distro like SuSE.

<snip> 
> Making symlinks is also too complicated for them. It should be automatic.
Well, what speaks against a small install-script doing this ?
Maybe this script may also paint nice pictures on the desktop and doing 
other useless things found in most "install programs" (like "install shield"
and all the other stupid stuff)

<snip>
> Or maybe you don't really understand the issue. Let's say you have the 
> application FooBar. FooBar's uses a PNG file as an icon in it's GUI. 
> When you type './configure && make install', the location 
> "/usr/local/share/foobar/icon.png" is hardcoded in the binary.
What if it is not ?
FHS-respecting people tend to have no /usr/local except for experimental stuff.

On network-installations you probably have several binary version, etc.

i.e. /usr/$(platform)/(bin|sbin|lib)/
     /usr/share/
     ...
     
Does model also work then ?

<snip>
> So what's the big deal here? One of Linux's problems on the desktop is 
> the ease of installing software. 
That's what end-user-distros are for.
They normally follow LSB, which help much.

Perhaps they differ in some libraries (ie. Suse does some strange things ...),
but Opensource packages normally can be ported to other distros (even non-lsb)
with quite reasonable work, and proprietary packages tend to bring along 
half an OS nevertheless.

<snip>
> We at autopackage are making a new installation system for Linux, which 
> also allows software to be installed to any folder (the default is ~/.local). 
> Many end users will like this because they don't have to type the root 
> password. This also prevents malicious software from wiping out the 
> entire system and other users' data.
What speaks against simply providing "userland" packages (simply compiled
with the right prefixes pointing to ~/.local) ?

> Anyway, back to the relocation thing. Because 
> "/usr/local/share/foobar/icon.png" is hardcoded in the binary during 
> compile time, FooBar can't be simply installed to ~/.local. FooBar must 
> be able to know where icon.png is. This is where the proposed function 
> jumps in.
Why hardcoded ?
Why not fetched from any available global config or an environment variable ?

As I already stated, there are many, many applications out there using 
this for about ten years.

FOOBAR_PATH=~/.local/foobar/

if you dont want to pollute your global env, you can easily set up an
alias:

alias foobar=`FOOBAR_PATH=~/.local/foobar $FOOBAR_PATH/bin/foobar $*"

Generating this by an install script is an really easy job.

<snip>
> Another example:
> FooBar is /home/test/.local/bin/foobar.
Where do you from, that bindir=$prefix/bin ?
And what happens when it is not ?
Or what happens when the process is called via some symlink ?

> Extract prefix -> /home/test/.local
> Append data file path -> /home/test/.local/share/foobar/icon.png

<snip>
> > Ah ?
> > where's the relation between pathes given by --bindir, --libdir
> > -sysconfdir and --localstatedir ?
> 
> (Example:)
> bindir = /usr/local/bin
> libdir = $bindir/../lib
> sysconfdir = $bindir/../etc
> etc. etc.
> Of course this won't work if the user specifically passed a different 
> path to configure, but we can check for that.
Well, that's the problem.

On FHS-conform installations, sysconfdir is normally /etc and not 
somwhere under $prefix (/usr), localstatedir is /var, but datadir 
is $prefix/shared, bindir=$prefix/bin, ...

> > cant the API be just getenv() ?
> 
> No, it can't, for a few reasons:
> - What when you have multiple versions of an application installed?
Call each version with its own env ?

FOOBAR_PATH=~/.local/foobar ~/.local/foobar/bin/foo

> - Environment variables are unique to each process and are copied by 
> fork(). You cannot change other process' environment variables without 
> modifications to the kernel. What when you install FooBar for the first 
> time? Let's say FooBar uses $FOOBAR_LOCATION. When you launch FooBar 
> from the GNOME panel or KDE panel, it won't work, because GNOME/KDE 
> panel don't have the $FOOBAR_LOCATION environment variable.
Well, then the gnome panel should simply reload its environment.
Simply call the shell as subprocess, let it read .profile or /etc/profile,
pass command "env" to it and pass the output to setenv().

<snip>
> >No, running the binary from somewhere is now problem, but expecting the
> >data being somewhere else than defined by the configure options (defaulting
> >to FHS) or under the homedir, but instead somewhere relative to the
> >binary is a problem for me.
> 
> As I said before, configure can check for that and disable relocation 
> support.
Well, what shall the application do w/o relocation support once it relies
on it ?

<snip>
> >Perhaps a separate library can provide these features
> 
> This *can't* be in a seperated library. We've developed BinReloc, a 
> small library for relocation. We talked to the Gimp maintainer. He 
> doesn't want to accept it unless it's in glib!
Well, that's his problem.
If there're many people crying for it, then I'd offer to maintain a 
separate branch and then let's see which one survives.

<snip>
> Platform-specific stuff (with fallback, of course) has to be 
> *somewhere*. If not in glib, then where else?
Why not in another lib sitting on top of glib, but also being 
platform specific ?

<snip>
> - Putting it in a seperate shared library will not work because people 
> want to avoid dependancies.
What is so bad on dependencies that evryone moans about it ?!
Its the job of buildfarm, package manager, etc to maintain dependencies.

For self-compiling folks there could be a small script putting all
the packages into a large tarball and publish it as a "complete-distribution"
on the ftp servers. Apache (httpd-2.x) exactly does this.

> - Putting it in a library that's supposed to be statically included 
> (BinReloc) does not work because people don't want *any* 
> platform-specific code (including #ifdefs).
eh ?
you mean by simply #include it to the main application ?
then where's the #ifdef in my application if I simply #include something ?

btw: there _ARE_ many, many of such #ifdefs, i.e. in libc.

<snip>
> In summary: this relocation problem is a big issue for *desktop users*. 
Could you please speficy "desktop user" ?

> Average users who just want their computer to Just Work(tm), without 
> having to dive into the commandline or recompile or making symlinks.
Who talks about commandline ?

There could also a pied icon on the desktop, which calls the actual
package manager in the background.

> Are you not supporting making Linux/Unix easier to use for those people?
> Or do you have a better idea?
Yes. I do.
I'm building heavily customized GNU distros, also for office systems,
for my customers ...

Well, I'm working on such problems (software distribution, quality
management in computing environments, ...) for many years and one of
the most pregnant thing I've learned is: giving the end-user to much
control over things the machine can do alone is a really bad and 
dangerous idea.

Also I've learned to follow these guidelines:

* with Wirth's words: make it as simple as possible, but not simplier.
* keep things small and lightweight.
    -> each line of code is an possible point of failure (or even leak!)
    -> each system should only contain as much code as necessary for working

* modularize where you can
    -> put distinct functionality into distinct modules
    -> circular module dependencies are absolutely forbidden
    -> module interfaces may never change, just be extended
       you may of course decide to stop supporting old interfaces
    -> a highter version of an module (or interface) must be 100% 
       compatible to lower versions.
    -> each module may only depend a fixed set of other modules
       (if multiple ones seem to be applicable, then they should be 
       encapsulated by an adaption layer)

* let the machine do as much work as you can
    -> tell the machine exactly this information which is needed to do
       a certain job (i.e. model the software's structure instead of 
       some rules for computing tool commandlines)
    -> everything should be reproducable.


These guideliens have been proven in practise - even they look a little 
bit too educational - and I'd really like to see them used in oss.

Up today glib/gtk is still much nearer to them that bloaty Qt.
(i.e. big thanks to the folks decided that pango, atk & friends should 
be separate modules - Qt goes the wrong way by putting too many things
into the lib, even those really not belonging, like RMDBS connectivity)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact metux de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
---------------------------------------------------------------------