> From: Bruce Dubbs <[email protected]> > Date: Sun, 2 Oct 2016 14:29:00 -0500 > Subject: Re: [blfs-dev] Perl modules > > 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. >
More-or-less ditto. Ken's note reads like some form of self-harming lost-sight-of-the-woods-for-the-tress really-need-to-stand-back-a-bit insanity: I would recommend strongly to use/track/include only (reasonably-)sanely-behaved software/dev practices. At the very most, perhaps include a 'perl modules reqd for *tex*' page in the tex section; and if nec reference the main current general perl-modules page. rgds, akh -- -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
