[nex-xsl] What to do?
Hi,
As you know, the new XSL stylesheets are ready for production time waiting the
release of stable DocBook-XSL-1.72.1.
The bad news it that there will be no DocBook-XSL-1.72.1 release, but a new
beta DocBook-XSL-1.73.0 that may contains several bugs due very intrusive
changes on how the package is generated from source code, changes on how
processing instructions are handled, and maybe other changes they are
planning before release.
That lead us to the next choices:
1. - Wait up to the next *.1 release to start using the new code. That could
meant to wait at least other 3-4 months :-/
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a installation
page for such package in BLFS and to install it on the servers and editor's
machines.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full auto-contained.
This will increase maintenance work to keep it sinchronized with upstream
code, but IMHO is the more simple solution and my prefered way.
Options 2 and 3 implies also that the DocBook-XSL page in BLFS could be
updated at least up to 1.71.1
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
M.Canales.es wrote:
Hi,
As you know, the new XSL stylesheets are ready for production time waiting
the
release of stable DocBook-XSL-1.72.1.
The bad news it that there will be no DocBook-XSL-1.72.1 release, but a new
beta DocBook-XSL-1.73.0 that may contains several bugs due very intrusive
changes on how the package is generated from source code, changes on how
processing instructions are handled, and maybe other changes they are
planning before release.
That lead us to the next choices:
1. - Wait up to the next *.1 release to start using the new code. That could
meant to wait at least other 3-4 months :-/
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a installation
page for such package in BLFS and to install it on the servers and editor's
machines.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full auto-contained.
This will increase maintenance work to keep it sinchronized with upstream
code, but IMHO is the more simple solution and my prefered way.
Options 2 and 3 implies also that the DocBook-XSL page in BLFS could be
updated at least up to 1.71.1
Manuel,
I know that you have been working hard on the updates, but options 2
and 3 seem to be even more work. On top of that, I suspect we will want
to go to the next stable release when it is available, so a lot of the
work done for options 2 and 3 would only be useful for a few months.
Do you have any insight into why there will be no 1.72.1 release?
My initial reaction is that option 1 is best for the overall project.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
M.Canales.es wrote these words on 07/04/07 15:34 CST:
1. - Wait up to the next *.1 release to start using the new code. That could
meant to wait at least other 3-4 months :-/
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a installation
page for such package in BLFS and to install it on the servers and editor's
machines.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full auto-contained.
This will increase maintenance work to keep it sinchronized with upstream
code, but IMHO is the more simple solution and my prefered way.
Since Manuel is the one doing all the work, I defer my vote to
whichever option he wants (#3). This way we can keep the new version
of FOP in the book, or at least not have to put the previous version
in as well.
--
Randy
rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686]
16:04:00 up 6 days, 13:55, 1 user, load average: 0.10, 0.14, 0.09
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
Bruce Dubbs wrote these words on 07/04/07 15:59 CST: My initial reaction is that option 1 is best for the overall project. I typed a long essay in reply to Manuel's question agreeing with Bruce. However, just as I was finishing it, I thought well, since Manuel is the one doing all the work, whatever he thinks is fine with me and deleted my post before sending. I'm sitting on the fence. As I said, I initially thought option 1 was best, but now ... -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 16:14:00 up 6 days, 14:05, 1 user, load average: 0.18, 0.22, 0.16 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
On Wednesday 04 July 2007 21:34:05 M.Canales.es wrote:
Hi,
As you know, the new XSL stylesheets are ready for production time waiting
the release of stable DocBook-XSL-1.72.1.
The bad news it that there will be no DocBook-XSL-1.72.1 release
That's obviously not the news any of us were hoping for!
That lead us to the next choices:
1. - Wait up to the next *.1 release to start using the new code. That
could meant to wait at least other 3-4 months :-/
While this is probably the easiest option to go for (all projects simply stick
with the current docbook toolchain), it would be a shame to see all of your
hard work on the new-xsl branch not made use of.
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a
installation page for such package in BLFS and to install it on the servers
and editor's machines.
This, I fear, would look as if we've created a fork of the upstream project.
While there are some good reasons for creating a fork (lack of maintenance,
undesirable license changes, etc.), the lack of a stable release when we
want/need one by is not one of them, in my opinion.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full
auto-contained. This will increase maintenance work to keep it sinchronized
with upstream code, but IMHO is the more simple solution and my prefered
way.
I also think this is the way we should proceed. I'm not sure that we
necessarily need to remove files that we don't require for a build of any of
our books - in fact, keeping them around would probably make diffs between
upstream and our downstream copy easier to understand.
Related to this issue is the fact that I'm painfully aware that the 6.3
release has been a long-time coming. Manuel, as you said, the current
snapshot in the new-xsl branch are production ready, so I'd be happy for
these to be merged, if this is the route that is decided upon.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
El Miércoles, 4 de Julio de 2007 23:29, Matthew Burgess escribió: I also think this is the way we should proceed. I'm not sure that we necessarily need to remove files that we don't require for a build of any of our books - in fact, keeping them around would probably make diffs between upstream and our downstream copy easier to understand. The files to be removed are almost all internationalization support files (keeping only the few ones used for current translators) and the highlighting/ files (used only by Saxon6). Thats around 5M of text files. What I'm afraid is that if the stable DocBook-XSL release take another 5-6 months we could start working on the Relax-NG migration before using the nex-xsl code :-/ -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
On Wednesday 04 July 2007 22:37:01 M.Canales.es wrote: El Miércoles, 4 de Julio de 2007 23:29, Matthew Burgess escribió: I also think this is the way we should proceed. I'm not sure that we necessarily need to remove files that we don't require for a build of any of our books - in fact, keeping them around would probably make diffs between upstream and our downstream copy easier to understand. The files to be removed are almost all internationalization support files (keeping only the few ones used for current translators) and the highlighting/ files (used only by Saxon6). Thats around 5M of text files. Oh, OK. That's pretty limited in scope then - seems to make sense to omit them from our repositories. What I'm afraid is that if the stable DocBook-XSL release take another 5-6 months we could start working on the Relax-NG migration before using the nex-xsl code :-/ Well, I took a look at the Relax-NG stuff a while back and hit a bug in libxml2 (http://bugzilla.gnome.org/show_bug.cgi?id=413248). That pretty much stops any work on migrating the stylesheets to be Relax-NG friendly. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
El Miércoles, 4 de Julio de 2007 23:49, Matthew Burgess escribió: Well, I took a look at the Relax-NG stuff a while back and hit a bug in libxml2 (http://bugzilla.gnome.org/show_bug.cgi?id=413248). That pretty much stops any work on migrating the stylesheets to be Relax-NG friendly. Actualy for DocBook-XML-5.0 libxslt2 is not useful as a validator tool due that it can't do RelaxNG+Schematron validations, at least for now. Plus, Bob Stayton said some days ago in the docbook-apps list that the libxslt maintainer confirms that libxslt will never support XSLT-2.0 -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LiveCD status request
Hello Everyone, Just a small hello and a request for some info. After a much-needed break, I have a bit more free time this summer and I'd like to do some work on the LiveCD. I've scanned through my LFS emails (although there's about 1700 of them waiting for me, so it might take a while to get through all of them), and it seems that there's not much development on the CD these days. Is that right? I'd appreciate an update on its status from anyone in the know. Also, if there are any suggestions/ideas on what could make the CD (as a project or the individual ISOs) more useful, I'd love to hear them. I'm hoping to spend some real time on it in the upcoming weeks, so any feedback would be very helpful. Sorry for the cross-posting, but I figured this might make a good opportunity for those who are interested in the CD but perhaps not enough to subscribe to its dev-list to make their thoughts known. Thanks! -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscript patches
Jeremy Huntwork wrote these words on 07/04/07 20:54 CST: I suppose this is a little OT, but it's semi-related. Has anyone ever considered adding chkconfig or a custom equivalent to our bootscripts package? A thorough explanation of the pros and cons (and appropriate URLs to the package homepage) of the above suggestion is welcome. It's hard to comment when it takes blindly researching the suggestion. -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 20:59:00 up 6 days, 18:50, 1 user, load average: 0.23, 0.29, 0.19 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscript patches
Jeremy Huntwork wrote: I suppose this is a little OT, but it's semi-related. Has anyone ever considered adding chkconfig or a custom equivalent to our bootscripts package? It would definitely make management and administration of the installed scripts easier Considered? Yeah. When I was working on the LSB-v3 scripts, I had started on a bash version of install_initd and remove_initd, using a functions file that could have been sourced by other scripts should the need arise. I lost scope about 3 arrays deep, while trying to keep the disk reads and writes at program start and exit only. I decided that bash really wasn't suitable and gave up on it. The current popular flavor of the LSB scripts are written in python, so it's a no go for the base LFS. I had considered adding a contrib directory to BLFS at a later date with the BLFS scripts that I had modified for LSB-v3 and including the already written python scripts (modified for the X-LFS headers), but have yet to discuss that on list. I'm not completely certain, but I don't believe that there is any interest in replacing the current scripts with an LSB style implementation at this time. Also noteworthy, the contrib scripts have not had any dash/ash testing and might be a step backwards in that regard. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
