Ken Moffat wrote:
I'm still working out the deps for the new version of biber - I have
them all now (more than 100 _plus_ LWP), including those needed at
runtime and for testing, it's just a question of which (minor)
dependencies need which other minor dependencies. At a guess,
probably no more than 5 levels of dependencies. And I'm not
bothering to separate runtime deps.
And some of the (many) perl module developers are less reliable than
others - frequent new releases, sometimes severely changing the
dependencies.
What we have been doing is to only list versions for the top-level
dependencies needed elsewhere in the book. The advantage of that is
that we don't fill up the comparison report with random new versions
of some minor depen dency. The downside is that any random change
can alter the dependencies (that happened to me in the past week,
took me ages to find out what was going on). And if/when that
happens, the listed dependencies become incorrect.
I'm increasingly thinking that we ought to list the version used for
each dependency - and to NOT automatically check for new versions
until either we are heading for a release, or until a package which
uses something has a new release which needs a later version (biber
tends to be good at that).
The other problem with the perl modules page is that it is long and
deep. Using versioned entities for everything would solve the
depth (only one level of dependency per module) but probably increase
the page length by at least two orders of magnitude.
Igor's fork of the book was mentioned this week - He has moved his
(three) modules into a separate chapter - although I think he is
missing some dependencies for the one I looked at ;-) A separate
chapter sounds like the way to go. Omitting texlive, and therefore
biber, obviously has benefits.
Changing this would be a major and protracted effort. I think
*something* needs to be done, but my initial change to add
unversioned entities for dependencies doesn't look as if it will
help as much as I had hoped. And to be honest, if it wasn't for the
pain caused by editing the biber deps I would much prefer to do more
interesting things such as bringing TTF/OTF fonts under control.
I saw that DJ added some modules without dependencies this week : if
you are reading this, how did you find the experience ?
Any alternative views ?
For the meantime I'm still working through the biber deps, that
will take some time and then I'll put them into the CURRENT page
(versioned entities for top-level deps, unversioned entities where
used by more than one other module).
My understanding is that the issue at hand is due to biblatex-biber. I am
not in favor of a massive increase in the perl modules page to just
accommodate one relatively minor package.
I think a section in biblatex-biber discussing the issue and suggesting
using cpan for the biber required modules would be sufficient.
Another option is to just drop the biblatex-biber portion of the book. If
a user needs it, there is always install-tl-unx. Adding a huge tail of
dependencies is really only needed for biber developers.
If it is dropped, it can be supplemented by a hint that does not need to
be updated every time a perl module is updated.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
