jm, I understand what you are trying to do, but I don't understand your mapping below.
/opt/ltsp/i386 --> /bin ? I don't get that. Building packages in the LBE is, for lack of a better term, a pain in the ass. I should know, I wrote the damned thing, and it's a pain even for me :) right-side up, or upside down, you still need separate directories for the tools and the final output, and your ./configure scripts are going to have to deal with that. Properly written configure scripts shouldn't have a problem, although you might have to help them along with things like '--foo-is-here=somepath' type args. Still, i'm happy to entertain the thought of flipping things around, if you can actually make it work, and the end result is better than what we have now. my guess is that you'll get something to work, but it will be no easier than what we have now. Hopefully, you can prove me wrong on that point. Jim McQuillan [EMAIL PROTECTED] On Tue, 28 Jun 2005, jm wrote: > Insane as I've not really thought this through and it's only a suggestion so > don't take it to seriously. It should also really go on the development list, > but I'm on too many lists as it is. So here we go. > > This motivated by the amount of trouble I've had compiling a few packages. > These are packages that I'm adding myself, so it's not a reflection upon the > main lbe package maintainers. Individual package are fine, especially once you > discover DESTDIR env variable for make. However, if you are trying to add > closely coupled packages, ie the second package is aware of the first and > queries it usually through some form of config program as to where parts of it > are installed. Now the installed package's config program knows nothing of > opt/ltsp/i386 so it will return paths like /usr/bin for parts of the first > package which the second package then complains it can not find as it's > looking from within lbe's root directory. > > Alright, that's looking about as clear as mud so let me demonstrate with an > example. Consider two packages p1 and p2. p1 is already installed in > /opt/ltsp/i386 and I'm trying to install p2. p2's configure script calls p1's > p1-config program to find where p1bin is installed. It receives the answer > /usr/bin/p1bin but as it's actually been install using DESTDIR or similar to > /opt/ltsp/i386 it's actually /opt/ltsp/i386/usr/bin/p1bin. At this point the > p2's configure script falls over complaining that it can't find p2bin. > > At the moment, I can think of a few fixes. patch the install scripts for every > package this effect - yuck. Symbolically link /opt/ltsp/i386/opt/ltsp/i386 to > / and compile programs with --prefix=/opt/ltsp/i386 so that when when > operating in the /opt/ltsp/i386/ root environment programs find their > components - still not very neat. Install a second copy of the first package > to lbe's root environment to fool the configure script of the second package - > this is what I ended up doing. Or, lastly, change the layout of lbe so that it > looks like a what the packages are expecting. > > This last one would involve building the packages in the root directory and > placing the lbe tools in a sub directory. Inverting the current arrangement. > The advantages here is that it looks like what people are already writing > packages for in most other linux, bsd, etc distributions and that it would > modifying the least number of packages as it is relatively easy to set up the > use of libraries and compile tools in a different path. The layout for this > would look something like this, > > existing proposed > /opt/ltsp/i386 ------> /bin > /bin /sbin > /sbin /tmp > /tmp /usr > /usr /var > /var /lbe > various src dirs /lbe/various src dirs > tools dirs /lbe/tools dirs > > then to create the root directory for ltsp you could either just export this > or copy everything except the /lbe directory. > > J. > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on irc.freenode.net > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
