On October 1, 2016 8:58:31 PM CDT, Ken Moffat <[email protected]> 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 ?
Prior to the most recent edit, that page had been one of those ones I didn't want to touch just because it's been historically delicate. Once I understood it, however, not so much difficulty as in the past. So, easier, yes. > >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). > >ĸen >-- >`I shall take my mountains', said Lu-Tze. `The climate will be good >for them.' -- Small Gods >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page > > >-- >This message has been scanned for viruses and dangerous content by >E.F.A. Project, and is believed to be clean. > >Click here to report this message as spam. >https://efa1.lucasit.com:8443/cgi-bin/learn-msg.cgi?id=5594560479.A7592&token=6b1a1efe2d815859b8b599267420a4cd -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
