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

[Mike Hearn <mike navi cx>]

On Mon, 12 Apr 2004 18:40:42 +0200, Enrico Weigelt wrote:
> Where could the binary location help here ?

I already explained that in the first email.

> The Admin just says what packages he wants and which feature should 
> be enabled in them. Its then the job of the machine to get the right
> binary packages installed on the system. The package source can be a
> local or remote repositiory or and buildfarm somewhere on the net
> (probably on the local machine or perhaps one someone's workstation)

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. 

> 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. 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. The API can be designed to
accommodate the cases where for some reason the admin/packager chose to
break that assumption.

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

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.

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.

thanks -mike