/usr/local/... Or /usr/... For .ipk Structure ?

[telemetric_au]

ive compiled some apps and making them into ipk's, is it important or relevant if their tree structure begins at /usr or /usr/local ??

ps im also looking for collie pdaxrom cross sdk, ...

[Da_Blitz]

you might want to read up on the file system stuff (http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/index.html)

however the rule of thumb i have is mount/boot/esential on / (as its the first thing mounted and bootstraps the system, you dont want mount to be ona partion you havent mounted yet)

/usr for everything else

/usr/local for stuff that you did yourself or only is for that machine

you have to remeber that in the old days / might have been RO or on a nfs drive or local to the system, it didnt matter but centralising it made things easier, /usr was almost certinally a nfs dir so that instead of having several machines to update you update the one and the updates are reflected in all machines at next launch of the program and /usr/local would be local storage for machine specfic tweaks and progs (such as if it was the only compile server, then the compiler would be in there rather than waste space in /usr

it works well if you implement network drives at ome, and i mean really well. you have te be careful with diffrent distros but i see why they did it that way along with nss to push /etc files to the machines

[Meanie]

you might want to read up on the file system stuff (http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/index.html)

however the rule of thumb i have is mount/boot/esential on / (as its the first thing mounted and bootstraps the system, you dont want mount to be ona partion you havent mounted yet)

/usr for everything else

/usr/local for stuff that you did yourself or only is for that machine

you have to remeber that in the old days / might have been RO or on a nfs drive or local to the system, it didnt matter but centralising it made things easier, /usr was almost certinally a nfs dir so that instead of having several machines to update you update the one and the updates are reflected in all machines at next launch of the program and /usr/local would be local storage for machine specfic tweaks and progs (such as if it was the only compile server, then the compiler would be in there rather than waste space in /usr

it works well if you implement network drives at ome, and i mean really well. you have te be careful with diffrent distros but i see why they did it that way along with nss to push /etc files to the machines
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159828\"][{POST_SNAPBACK}][/a][/div]

that's a very nice and concise summary of the design and usage of unix type filesystems layouts, however, it is not very likely that anyone is going to deploy a farm of Zaurii for everyday usage. We humans are limited to two hands only

As to the original question, on pdaXrom, most packages have been streamlined to be at /usr, but most packages if you just compile them without setting the prefix will be at /usr/local
Some of the window managers used in pdaXrom have limitations when evaluating the desktop files and icons for the menu items so it would make it easier for you and others to have at least /usr/share/applications and /usr/share/pixmaps, ... the rest doesn't really matter... but you might as well be consistent...

[telemetric_au]

np

[Da_Blitz]

i wolud love to see a better place for program specific scripts, chucking them in /lib or /usr/lib dosent seem right as to me they are programs not libries (well actuually depends if you "." them or ./ them)

i know d-bus does that as i had to hack one to get S3 working on the kohjinsha (works great, i even get a nice rainbow on bootup (ie framebuffer in bizzare state)). problem was that the kohjinsha is not a recignised s3 platform so i just added a --force flag somwhere and did vbe stuff but now im off topic

actually the FHS can teach you alot, but your right i dont know how many people are going to set up a render farm of Z's but i did use it to great effect at home without network drives by making /usr/local its own lvm partion so that between distro upgrades/changes i didnt lose my compiled apps (most apps default to /usr/local when compiling)

same reason i have /home on its own partion, in fact its the same data from my first linux install 3 years ago (has it been that long). it was the best advice i colud have taken or given to anyone starting out. (one sidenote, im not still uning the original drive i did for /home but i have migrated the data scince then, so its still the same settings i have had for 3 years)

basiaccly if you dont want to read the above it comes down to this, they did it that way for a reason. read the history to find out way they did. it worked then and it works now, there may be better ways but this is proven

[desertrat]

I when first started packaging stuff I used "/usr", but then when I found that there is no easy and consistent way to tell "make install" to put files into a specific directory. This made things tricky since I didn't want "make install" to install into my live system but rather to a directory eg "/home/me/temp-ipkg/usr", where I can review the files installed (maybe removing stuff that aren't needed like docs, manpages, etc) then run mkipkg on it. The only consistent way to force installation to a specific directory was to remount the destination directory that "make install" uses, but the big problem with this method is that if you remount "/usr" onto "/home/me/temp-ipkg/usr" then if "make install" needed to use any programs or libraries/headers that were under "/usr" they're not available anymore and hence fails. This becomes less of a problem if you use "/usr/local" because "make install" would be less likely to need any of the stuff in there.

Anyway after a while I learned that I could edit the Makefile and manually add a prefix to the installation directories and hence install to anywhere I choose without having to do the remount stuff. But the habit of "/usr/local" stuck

[desertrat]

same reason i have /home on its own partion, in fact its the same data from my first linux install 3 years ago (has it been that long). it was the best advice i colud have taken or given to anyone starting out. (one sidenote, im not still uning the original drive i did for /home but i have migrated the data scince then, so its still the same settings i have had for 3 years)

Heh, my ~/ dir is from my first installation of Linux from about 7 years ago - a Redhat 7.x, I have since changed distros (Mandrake, Debian and currently Gentoo), several computers and numerous hard-disks later and basically my home directory contents and more importantly my program settings have migrated safely. This is in sharp contrast to windoze where you would be extremely lucky to find all the places in the registry where a particular app hides its configuration.

[Da_Blitz]

its the number one reason i kept on going with linux, imagine a noob trying to set up debian (yep that me). it was great because if i stuffed somthing up that badley a rebuild was a no brainer (i mean setting up linux, with patches and settings + progrs installed takes less than an hour compared to my 2 day estimate for windows)

as for install paths, i never had a problem with --prefix=/usr to install to /usr when builing with config scripts

as a side note what do you guys do besides /home on a seperate partion to make thins eaiser, me personally i have a downloads folder (handy as it dosent clutter the desktop) a vfs folder (virtual file system, with symlink to /media and a whole lot O' fuse, great for the command line) and rm as an alias for "mv ~/.Trash" so rm behaves like delete under gnome and i can recover the files (done that one too many times)

best bit about the rm trick is you dont then need to specify the -r flag to decend into a dir

[desertrat]

... installed takes less than an hour compared to my 2 day estimate for windows)

Waiting for windoze to reboot after every little change probably accounts for 3/4 of that time.

as for install paths, i never had a problem with --prefix=/usr to install to /usr when builing with config scripts

Er, if you let "make install" install into the live "/usr" how do you figure which files it installed and where?

[Da_Blitz]

trick is to use --prefix to dump to a temp build dir such as --prefix=/home/dablitz/code/progect/build, that way it facillitates packing it up for shipping, then do some majic with ls flags and you get a nice dump of which files are where, whhen you are happy cp -a them over (preserves permissions) or tar if you want

but what you asked was installing to a live system, well you colud rip apart the "install" part of the make script, should just be a whole lot o coppies or there was a fuse module called "logfs" which should give you a listing of what went where

to use logfs you need to create a temp dir, mount logfs to copy / onto the mountpoint, chroot <mnt point> /bin/sh into it, then run the make from there

if there isnt a configure script to run then i recomend looking in the Makefile for a PREFIX= var or look at the install section and possibly patch it if it dosent

hope that answers your questions, i get a feeling i missed somthing such as the question  haha till next time

[koen]

trick is to use --prefix to dump to a temp build dir such as --prefix=/home/dablitz/code/progect/build, that way it facillitates packing it up for shipping, then do some majic with ls flags and you get a nice dump of which files are where, whhen you are happy cp -a them over (preserves permissions) or tar if you want
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159930\"][{POST_SNAPBACK}][/a][/div]

Or better use '--prefix=/usr' and do 'make install DESTDIR=/tmp/something', that way things that hardcode paths won't break.

[Da_Blitz]

ahh good point

i remeber that happenend in a OZ build once with o couple of the programs, they were looking for files in hrw's home dir

good times

[koen]

ahh good point

i remeber that happenend in a OZ build once with o couple of the programs, they were looking for files in hrw's home dir

good times
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159937\"][{POST_SNAPBACK}][/a][/div]

That's still true for apps with a broken buildsystem (git, bison, etc). Those apps don't look at prefix or destdir, but hardcode $PWD

[ZDevil]

trick is to use --prefix to dump to a temp build dir such as --prefix=/home/dablitz/code/progect/build, that way it facillitates packing it up for shipping, then do some majic with ls flags and you get a nice dump of which files are where, whhen you are happy cp -a them over (preserves permissions) or tar if you want
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159930\"][{POST_SNAPBACK}][/a][/div]

Or better use '--prefix=/usr' and do 'make install DESTDIR=/tmp/something', that way things that hardcode paths won't break.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159931\"][{POST_SNAPBACK}][/a][/div]

That's how i package things for pdaXrom all the time. But from time to time the configure in some sources are not smart enough to handle make install DESTDIR, unless one has expertise to modify them.  

[desertrat]

trick is to use --prefix to dump to a temp build dir such as --prefix=/home/dablitz/code/progect/build, that way it facillitates packing it up for shipping, then do some majic with ls flags and you get a nice dump of which files are where, whhen you are happy cp -a them over (preserves permissions) or tar if you want

If you point --prefix to a clean directory then there should be no need for "magic with ls flags", you just delete what you don't need then package what's left. However, the reason I don't use an arbitrary --prefix is that some apps hardcode the prefix into the app and expect you to really install into the specified --prefix or pukes up otherwise. Eg. If I use --prefix=/home/me/usr, package it and then install the app into /usr it will complain.

but what you asked was installing to a live system, well you colud rip apart the "install" part of the make script, should just be a whole lot o coppies

If you have a moderately complex app there could be loads of subdirectories and other complications making it a major pita

or there was a fuse module called "logfs" which should give you a listing of what went where

Not much help on the Z as the fuse module doesn't work

Or better use '--prefix=/usr' and do 'make install DESTDIR=/tmp/something', that way things that hardcode paths won't break.

Unfortunately not all configure scripts add the DESTDIR prefix. That's why I have manually edit the Makefile to add it in.