OESF Portables Forum
General Forums => General Discussion => Topic started by: telemetric_au on April 26, 2007, 12:47:31 am
-
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, ...
-
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
-
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...
-
np
-
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
-
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
-
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.
-
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
-
... 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?
-
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
-
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.
-
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
-
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
-
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.
-
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.
-
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
-
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
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159880\"][{POST_SNAPBACK}][/a][/div]
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
-
ps, how what changed do you make to the Makefile ??
-
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
ps, how what changed do you make to the Makefile ??
Search the Makefile for the "install:" section. An example for qbedic:
install: $(TARGET)
install $(TARGET) $(DESTDIR)$(PREFIX)/bin/$(APPLICATION)
Example for zlib here:
https://www.oesf.org/forums/index.php?showt...ndpost&p=160653 (https://www.oesf.org/forums/index.php?showtopic=23910&view=findpost&p=160653)
-
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 .
-
which is what it was intended for
-
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.
-
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>
-
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>
[div align=\"right\"][a href=\"index.php?act=findpost&pid=161033\"][{POST_SNAPBACK}][/a][/div]
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
-
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)