2008/3/5, DJ Lucas <[EMAIL PROTECTED]>: > Alexander E. Patrakov wrote: > > > > So, please express your ideas in the following areas: > > > > > First and foremost, SLOW DOWN!!!! How about some baby steps instead of > leaps and bounds. The recent threads are going nowhere because we have > 20 individual topics crammed into one thread. There have been 4 now > that have all resulted in no clear direction. DESTDIR sounds like a > logical first step. I've excluded the rest of your message as it > doesn't seem useful just yet. Again, knowing nothing about the various > PMs, I've made some assumptions. Can someone confirm or deny those for me?
Let's try. It is good that you don't forget that there are people that think that DESTDIR is a wrong approach, and also note the fact that most non-DESTDIR approaches can be applied to the corrent book without the need for such extensive modifications. > For RPM, I've made the assumption that you take a spec file and a source > tarball, and create an installable binary package, then install that > package. I don't suppose that the second step is automated only by rpm > itself, so the installation portion is different. I expect that, but > are the configure, make, make install commands the same for all DESTDIR > methods? Looking at different PMs, how much will be in common WRT to > CMMI? I'd say, 90% if you avoid RPM-specific idioms. You can look at my spec files in the "RPM: proof of concept" mail and see yourself. > On DESTDIR installs, DESTDIR can be an exported environment variable and > the target cleaned out after every installation is completed. This may interfere with the way Makefiles get environment variables. > If that > is possible, then the no PM group, the install-watch group, and the > timestamp group are completeley unaffected by the changes for a mass > majority of the packages as DESTDIR="". I'm looking for simplicity in > common instructions first. Again, take some baby steps, one thing at a > time. Lets try not make things so complicated just yet. If the above > handles getting DESTDIR into the current book, with such simplicity, > then get that part done first. Explicitly set DESTDIR="" for the first > cut and the book still works as is. If not, then if you would be so > kind as to explain away my assumptions, it'd be much appreciated by me > for certain, but would help in educating the rest of the readers as well > WRT RPM anyway. Also, the same goes for other DESTDIR PMs that anybody > would care to explain. Yes, DIY uses this fact. They require the reader to set $PM_DEST to an empty (no PM) or non-empty (PM) value, and run things like "make DESTDIR=$PM_DEST install". However, for some packages, this may need a command like "mkdir -p $PM_DEST/etc" before this. Also note that post-installation steps are required in all DESTDIR-based methods (e.g., to register info documentation correctly), and that all configuration files have to be marked as such in order to avoid their overwriting. "DESTDIR alone" is just broken, so a baby step leads to a hole in the ground. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
