On March 10, 2017 10:58:32 AM CST, Pierre Labastie <[email protected]> wrote: >On 07/03/2017 22:19, Bryan Gonzalez wrote: >> Yes >> >> On Mar 7, 2017 3:57 PM, "Pierre Labastie" <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, >> The last stable version of jhalfs dates back 2009. The SVN >version >> has de facto become the only usable one on latest versions of the >> book. >> Having a rolling release is nice, but it prevents big changes to >> be done, because each revision should just run "as usual". >> However, making big changes may be interesting sometimes, to >> implement new features, or changing the design of some parts to >> ease maintenance, etc. In order to render possible development >> without depriving users from their usual tool, the solution is to >> make a stable release. Then development could be going forward >> along the following lines: >> - always generate test instructions, but comment them out a >> according to the menu settings: suppose you want to just run the >> tests for a problematic package, but you do not want to run the >> long glibc, gcc, autotool, perl... tests. Right now, it is almost >> impossible: you'd have to enable all tests, and then comment out >> the ones you do not want in the scripts. If instead you can >> generate all tests already commented out, you would just have to >> enable the tests you want. Of course, the various existing >options >> would remain: all tests commented out, all but critical tests >> commented out, only chapter 5 tests commented out, or no test >> commented out... >> - refactor lfs.xsl with more named templates (equivalent to >> functions in .xsl), so that modifying and/or maintaining is >> easier: right now this stylesheet is a spaghetti soup, with >> duplicate code, convoluted <xsl:when> alternatives, and so on. >> - introduce a way to update LFS without rebuilding everything >> (except maybe for some packages like glibc). Needs information on >> what version is installed and whether there is a newer version. >> - if we have a stable version somewhere, we could even remove >some >> parts of the code, which are for supporting old books... >> >> So I propose to work towards releasing a stable version with what >> we have now. Let's say it would be 2.4, with bugfixes and >> backports from development coming as 2.4.1, 2.4.2, etc. >> >> For doing so, I guess it would be better to update dpkg and >pacman >> versions, with hopefully not too many other changes. This could >be >> done within the next days. But feel free to comment on what >should >> be done before that. >> >> Then, unless it comes out that it is more difficult than >> anticipated, tag a 2.4-rc1, next week, say on Wednesday 15th, and >> have people test as much as they can... >> >> Then make the release, say fifteen days later or so. >> >Thanks for the answer. Unless somebody speaks up, I won't update the >pacman files before release: upstream have removed the possibility to >build as root, and to accommodate, that, it would necessitate big >changes to the way scripts are generated. Let's move this to after the >release. >
Sounds good to me. You could recommend backing out the change in Pacman, or building a binary with and without specifically for jhalfs if desired, but still something to be done after the release. IIUC, a stable release is desirable at this point so that experimental can trickle into trunk (or just go in). --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
