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

[Enrico Weigelt <weigelt metux de>]

* Mike Hearn <mike navi cx> [2004-04-12 19:54:00 +0100]:

<snip>
> And if they wish to install to a non-standard prefix there will be no
> binary packages available to them, so they must compile their own. 
Or let request the buildfarm to generate the missing package. 
Perhaps throwing some symlinks will also help.

<snip>
> > Fetching the data location from the binary location is in general a 
> > very bad idea.
> 
> I disagree. I think it's an excellent idea, and the amount of prior art
> for it would seem to back me up here. 
Whats speaks against respecting FHS ? 

Or why not using the environment ? 
Many, many applications can read their config or data location from 
environment variables, i.e. mutt, procmail, postgresql, ...

<snip>
> While configure scripts can be used to alter the places where various types 
> of files are installed to, data is almost always predictably relative to 
> binaries. 
Ah ?
where's the relation between pathes given by --bindir, --libdir, --sysconfdir
and --localstatedir ?

<snip>
> The API can be designed to accommodate the cases where for some reason 
> the admin/packager chose to break that assumption.
cant the API be just getenv() ?

<snip>
> > Yes, some windows applications tend to install themselves
> > under some directy, which the user has to type in before installation,
> > and also stores user-data under this directory. But this is principle
> > mis-design and should not be supported by toolkits like glib.
> 
> If you're going to make assertions like that, I'd expect you to back them
> up. You haven't bothered explaining the ability to run from any path is
> "mis-design" though.
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. Perhaps you decide to move some binaries to 
a different directory and throw some symlinks (i.e. for splitting to 
multiple partions or even network installs), then you'll ride into trouble.

> But anyway, regardless of whether it's mis-design or not, it's standard
> practice on Windows, and it's not the place of glib to try and force the
> UNIX FHS on Windows users.
Why not ?
BTW: it doesnt necessarily need to be FHS, but something similar, which 
splits the directory tree into several semantic parts.
(along those borders which are defined by --sysconfdir & friends)

<snip>
> Now if you have some *specific* objects to this proposal, I'd like to hear
> them. Arguing about package management techniques or the design of Windows
> is not productive however.
Feeding up glib with dozens of hacks which only make sense on some 
dying platform is also not productive, since the more glib gets inflated, 
the more people will run away from it.

Perhaps a separate library can provide these features, perhaps this can
also do some more general path/location handling stuff, but glib itself
should not grow anymore, if not really really necessary.


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 --
---------------------------------------------------------------------