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.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
