Help - Search - Members - Calendar
Full Version: /usr/local/... Or /usr/... For .ipk Structure ?
OESF Portables Forum > General Forums > General Discussion
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
QUOTE(Da_Blitz @ Apr 26 2007, 05:28 PM)
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
*


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

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 smile.gif
desertrat
QUOTE(Da_Blitz @ Apr 26 2007, 01:20 PM)
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
QUOTE(Da_Blitz @ Apr 27 2007, 04:35 AM)
... 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.

QUOTE
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 wink.gif haha till next time
koen
QUOTE(Da_Blitz @ Apr 27 2007, 08:49 AM)
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
*


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 smile.gif
koen
QUOTE(Da_Blitz @ Apr 27 2007, 10:44 AM)
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 smile.gif
*


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
QUOTE(koen @ Apr 27 2007, 10:55 AM)
QUOTE(Da_Blitz @ Apr 27 2007, 08:49 AM)
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
*


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



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. smile.gif
desertrat
QUOTE(Da_Blitz @ Apr 27 2007, 08:49 AM)
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.

QUOTE
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 smile.gif

QUOTE
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 sad.gif

QUOTE(koen @ Apr 27 2007, 08:55 AM)
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.
Da_Blitz
ahh, sorry the majic with ls flags is if you want a listing of all the files, may come in handy esp. if you installed to a live system and want all the files you need to delete wink.gif
telemetric_au
QUOTE(desertrat @ Apr 27 2007, 03:47 AM)
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 smile.gif
*



well i get some more of why i find this post usefull... basically ivebeen using the --prefix=DESTDIR, then packaging that up, installing it from reultant ipk and then removing the compiled source directory...

but things havent been compilnig so sweetly and i worked out why... now ive got the programs with prefix references inside them to onld locations, and they are passing that onto my compiling app when it asks for it... so then it looks there and it aint there no more... so im thinking i need to change my approach and recompile all my apps sad.gif
telemetric_au
ps, how what changed do you make to the Makefile ??
desertrat
QUOTE(telemetric_au @ May 10 2007, 08:01 AM)
but things havent been compilnig so sweetly and i worked out why... now ive got the programs with prefix references inside them to onld locations, and they are passing that onto my compiling app when it asks for it... so then it looks there and it aint there no more...
That is the problem that my post (#15) talks about

QUOTE(telemetric_au @ May 10 2007, 08:09 AM)
ps, how what changed do you make to the Makefile ??

Search the Makefile for the "install:" section. An example for qbedic:

CODE
install: $(TARGET)
       install $(TARGET) $(DESTDIR)$(PREFIX)/bin/$(APPLICATION)


Example for zlib here:
https://www.oesf.org/forums/index.php?showt...ndpost&p=160653
telemetric_au
ill look into this more, ive just been having some good success using the make DESTDIR=... install, ive recompiled most my apps, and its working well. i ahve heard of reports of it not working with all apps though...

i did have a go at mounting usr/local but what is the command to mount a directory rather than a block device ??

also in summary of the question of this thread, id say i have to prefer /usr/local, as i started out think usr for some time because it meant less typing for one thing !! but now i like /usr/local more as most apps install with that as "prefix" by default, and lets you keep/see your own additions seperate to what ever came with your OS/ROM .
Da_Blitz
which is what it was intended for wink.gif
pelrun
On pretty much every unix-like platform I've used, /usr is for apps installed from packages (and which can be likewise uninstalled) and /usr/local is for the messy stuff you compiled and installed yourself.

Since most people don't bother packaging things up, sources generally default to /usr/local. But just because that's the default doesn't mean that's what you should use for a package!

I know I'd be displeased if a self-compiled app installed itself in /usr, and I'd be equally displeased if I installed a package and it went into /usr/local! I know I'm not going to break packages if I do anything manually under /usr/local. And I know not to do anything manually under /usr for the same reason. Mixing them up is bad practice.
Da_Blitz
what you want is a bind mount, it binds one dir to another. be gareful with it as wierd things can happen (gentoo install, dont ask)

mount -o bind <real> <new>, where <new> is a copy of <real>
telemetric_au
QUOTE(Da_Blitz @ May 11 2007, 07:36 PM)
what you want is a bind mount, it binds one dir to another. be gareful with it as wierd things can happen (gentoo install, dont ask)

mount -o bind <real> <new>, where <new> is a copy of <real>
*


ah nice .... this feels very smooth and sleek, i understand the possible problem of missing "system" binaries though.

but its still a great option. especially when you app doesnt listen to DESTDIR as ive recently been runnning into...


i can also se how things could get interesting if you ended up with an indirect loop say through other "mount's" as well


though one problems ive been running into with this is that the base generic directory structure is missing and causes install error... not big issue though
Da_Blitz
actually the probelm i had was with /dev mounted as a tmpfs and proc

basically i unmounted them in the chroot and it did wierd things, not to mention the /proc and /chroot/proc were compleattly diffrent (caused me alot off confision)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2018 Invision Power Services, Inc.