On Sun, Aug 16, 2015 at 01:34:01PM -0700, Paul Rogers wrote: > I built cpan, OpenJDK & LibreOffice relatively recently for my current > 7.2 system, newer versions. I must preface with an apology if it seems > I'm all too willing to commit someone else's system. > > > > Good question! I haven't built LO for a while... So I do not know. I > > > think I never realized that there were downloads occurring during > > > the build process... > > > > > > Back to OJDK: if the procedure from the OP is acceptable for the > > > book, I'll be happy to include it, but I does not prevent the need > > > for storing files (at least java binaries and probably jtreg) on > > > anduin. > > In my opinion, there is a big advantage to having versions of packages > that are known to work with the book on anduin. When they reside on > other systems, others are in charge of the updates and replacements, > which does the BLFS builder little good with the instructions (s)he has, > even if changes are documented somewhere on those other systems. >
First, I think you put too much faith in "known to work with" : in some places we have alternative instructions (/usr and /opt) and it is not always true that both variants will still work. More generally, different combinations of optional dependencies have sometimes caused the book's instructions to fail - both get fixed, but only after somebody kas noticed the breakage and someone has found a fix or workaround. > > Yes, we've set the precedent with LibreOffice so downloading within > > the build process is acceptable even though it's not the first choice. > > Nor mine. My preference would be for the BLFS team to capture and save > a complete package that is known to work with the book's instructions. > It isn't a complete single package for the downloads made by LO, it's a series of git snapshots. Look at your build log! As I said, I used to keep local copies of the downloads - but each time we updated the book they were redundant, and from time to time the _method_ to load them into the directory appeared to change. In the end I gave up because even just trying to keep a local copy was too much aggravation. > > I'll note that the cpan method of perl modules does the same thing. > > One could also mention Modular XOrg I think. > I don't follow that - sure, the packages are probably not on anduin, and certainly not in the main wget list, but the Xorg downloads are almost always available from upstream (i.e. barring temporary disk failures). Anyway, many of the Xorg "applications" and most of the fonts are unnecessary on a modern desktop. > cpan is a case in point. I had difficulty resolving the book's > instructions with the current versions in cpan. Even what was currently > on cpan often had conflicting dependencies. It took a couple weeks, but > I finally resolved a version set that seemed to play together without > too much conflict, and tarballed them all together. I know that my > build script and this tarball will work. For your current versions of the packages which use them. I periodically update my "outside BLFS" perl modules (most of them are pulled in so that I can run perl testsuites, typically for modules needed by biber and similarly for their dependencies). It's two months since I last did that - when I next do it I expect to find that an obscure testsuite now needs one or more extra modules - and using the automated install from CPAN always runs tests, so that will pull in the new deps. Very quickly, your set of modules will be out of date. I know you are not fussed about using "the latest and greatest", but BLFS has always been about using current versions unless they turn out to be broken. Oh, and if I sound grumpy, I am - not at you, but at my current qt build failure. ĸen -- This one goes up to eleven: but only on a clear day, with the wind in the right direction. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
