No, he touches a serious issue. Just one example - the original Unix had only /bin, /dev, /etc and /usr, that's it. Then users asked the place to put their files which are common between them ---> /usr/bin and a couple of directories were created under /usr.

Later the same history cycle turned again at least twice with /usr/local and /usr/share. Finally we have /opt and the issue of structuring it is under way to us.

Yet again endlessly arguing about the same thing....

Places where the private libraries and resources are stored:
C:\Program Files\<appname> <=> /usr/lib/<appname> (arch dependent) ,/usr/share/<appname> (arch independent)
GNU makes an extra distintion here. Other than that, mostly the same.

Places where shared libraries are stored:
C:\Windows\System32 <=> /usr/lib
No difference.

Places where binaries that should be on PATH are installed:
Windows: C:\Windows\Sytem32 or create a private dir and add to %PATH%
GNU: /usr/bin or create a private dir and add to $PATH

What's the diference again? None. This is not an FHS issue.

What he wants is a package manager that asks where to symlink /usr/share/<appname> and/or /usr/lib/<appname> into, and we reviewed a lot of that stuff when discussing the /opt problem, didn't we?

The one I proposed is still on brainstorm...

With most Windows installers, i am not restricted to just under C:\Program Files\ , if i want i can install it straight on C:\ ,or i can go C:\Documents and Settings\username\potatoes\bananas\ , or i can install it on C:\random folder name\another random name\gibberish\ , or i can install it in a DVD-RAM disk, or in a pen-drive, or on a network shared path etc, and "appname" can be whatever i want, even nothing (which would mean the folder i put it in)

edit: and the launch shortcuts etc, and the program itself, as long as where it is installed is currently avaiable when i launch it (and in some cases while its running) etc, everything will work just as if it was installed in the default location (except in cases where dumb/lazy programmers hardcoded paths)

With most GNU/Linux software installers, i am not restricted to just under /usr/share/, if i want i can install it straight on / ,or i can go /home/javier/Xilinx/ISE , or i can install it on /opt/xilinx/ISE , or i can install it in a DVD-RAM disk, or in a pen-drive, or on a network mounted path etc, and "appname" can be whatever i want, even nothing (which would mean the folder i put it in)

In fact I'm typing /mnt/Opt/xilinx/ISE_DS/ into the Xilinx ISE installer as I was writing this post.

Where are those installers and why pretty much all programs i've found to install on the N900 don't use them?

that cant be helped

You have that kind of "culture" in every os.

i've been there too.

In windows, i really HATE how programs decides the names and the pathes of the variables inside the windows registry. I really want to change the names, or at least, to let the programs to change the registry keys names and pathes in the installation procedure, and i feel exactly like you, it cant be done. i only must accept it

in linux, i have the same situation: packages decides the pathes, and that cant be changed.

in the linux way, the world doesnt ends there: everything has a workaround.

For me, the solution has been to use GENTOO, another linux distribution that lets you to install your programs where you want them.

Not everyone needs it, thats why the linux distribution method works, and everyone in peace.

Maybe you could try it too.

Is there GENTOO for the N900? Does it have any downsides when compared to Maemo5?

@tiagotiago. Nop, gentoo is not ready to be installed into n900.

n900 has an specially modified linux distribution that is called maemo.

Some people are trying to port several linux distributions to the n900, afaik no one is trying to do it with gentoo yet.

i can't blame them: its like trying to install windows xp in the new notebooks designed for windows 7, its not an easy task.

What we what is a maemo powered device, this operating system has A LOT of predefined configurations, a lot of them are really questionable, but that is what we have

Something that changes the operating system behaviour can be called as "hack de device".

almost everything is possible, because is a gnu/linux powered device, that doesnt mean that everyone can do it. it can be hard

There is where the fun begins!

Now that's a good question.

On the N900*, you don't generally use installers, but use what's called a "package manager". A package manager's mission is, by definition, to allow installation of new software (and removal) requiring the least amount of effort from the user.

Why? Because traditionally, the amount of extra applications a user installed on a pristine GNU/Linux environment is so large that having to answer a single question for each of them quickly becomes unmanageable, as the first distributors and LFS users quickly discovered. So they devised a way to install new software with the user just selecting the new 37,000 packages of software he wanted to install and not having to answer any other single question (or just the most important ones).

Long time ago someone decided not only to make Maemo a Debian-forked distro but also to make the preferred third party software distribution method Debian packages (whoever made this decision could as well have decided that they want a "installer" based method!!).
I'm sure one of the reasons for going with a package manager is that they did agree with the mission of a package manager: that is, to make it easy to install software -- no questions asked.

Now, I personally agree with this decision, because nearly every time a installer asks me a question I leave the default setting as is and move on. This does include the "path for private sources/binaries" question.

Note the use of the "nearly" keyword in the above paragraph. This is because on the Nokia Internet Tablets, the root file system has been generally smallish. Since the root file system is the place where the "path for private sources/binaries" defauls to, one could easily find himself filling such a small space.

Such a user would need to devise alternative ways of installing software, or configuring the package manager appropiately, or even use the poor man's solution (but still quite effective!!) of symlink /usr/share/<appname> to /some/place/I/want/. (Note: explaining symlinks is outside the scope of this post).

What happened then? Well, as the "path for private stuff" question rose in importance, it started to make _less_ sense for package managers to NOT ask it. And -- behold! They started ASKING for it!

Get a N810 and try to install OpenTTD. It will ask you wheter to install to the internal card or to the external SD card.


On the N900, "the makers" realized in what I can only call one quite embarrasing moment that its rootfs was plainly too small for normal usage. So they devised a plan, not unlike what N8x0 packagers used to do with large packages, where certain packages would install into the internal card (aka /opt) instead of the smallish rootfs. This process is what is called "optification".

With such a setup, again it stopped making sense for package managers to ask where to install software, because the default place was again good enough for a majority of users. So, the OpenTTD package for the N900 doesn't ask you where to install it.


To sum it up,
- Where are the installers?
Guidelines for the N900 suggest not to use them but use packages for ease of use.
- Why does my package manager not ask for a path when installing a package?
Because a majority of people thinks such a question is useless, as the default is OK for them.
- Does this mean I'm forced to install to the default location?
No; see this very thread or the discussions we used to have about optification a year ago for information.


*Note that the N900 specially has quite a lot of extraneous limitations. Namely, "installing apps to an SD card" would be quite impossible usually because no one asked N900 developers to ensure our applications would be installable into a Windows filesystem a.k.a. FAT (and not a real filesystem with support for POSIX elements and attributtes).

Many windows installers got a command line option for "unattended mode"..... *pouts*