Re: [blfs-dev] Perl modules

[Bruce Dubbs]

Ken Moffat wrote:

On Sun, Oct 02, 2016 at 02:29:00PM -0500, Bruce Dubbs wrote:

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.


[...]


Any alternative views ?



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.



Having beaten biber itself into shape, I'm reluctant to see that go
to waste by using the binary.  Equally, I'm not keen on telling
people to use cpan.  If people want to use cpan after looking at the
deps, that is fine (I used cpan myself when I first built
Mail::SpamAssassin).

I'll go back to mapping out the deps.


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.



Again, -1.


I understand, but lets not pollute the perl modules section of the book 
with 50 additional modules only needed for biber.  Just create a section 
for that in the biber page or at least in the Typesetting chapter.


My rationale is that when I do a fresh build, I generally do all of the 
perl modules when I get to the first package that needs any perl module. 
I suspect there are others that do that.  OTOH, I rarely if ever build 
biber.  I have never found a need to use it.  It would be hard to pick out 
those perl modules only needed by biber and would make the perl modules 
page far less usable.


  -- Bruce


--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Perl modules

[akhiezer]

> From: Bruce Dubbs 
> 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

Re: [blfs-dev] Perl modules

[Ken Moffat]

On Sun, Oct 02, 2016 at 02:29:00PM -0500, Bruce Dubbs wrote:
> 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.
> > 
[...]
> > 
> > Any alternative views ?
> > 
> 
> 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.
> 

Having beaten biber itself into shape, I'm reluctant to see that go
to waste by using the binary.  Equally, I'm not keen on telling
people to use cpan.  If people want to use cpan after looking at the
deps, that is fine (I used cpan myself when I first built
Mail::SpamAssassin).

I'll go back to mapping out the deps.

> 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.
> 

Again, -1.

ĸ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

Re: [blfs-dev] Perl modules

[DJ Lucas]

On October 1, 2016 8:58:31 PM CDT, 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 ?

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=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