On 03/23/2018 02:56 PM, Ken Moffat wrote:
Catching up with what has changed since my last build, I got to ntp.
This added links to search.cpan.org for the perl modules it now
requires.
In my opinion, required deps should be documented in the book rather
than external links. For perl modules we have listed modules, and
any dependencies, but only applied versioning for whichever module
is at the top of the dependency tree (they are all on one xml page,
which is large and somewhat unpleasant to edit).
To try to put that in perhaps more readable words: if foo:bar is
needed by something outside of perl, we use the current version e.g.
foo::bar-1.23. If it pulls in other modules which are not
referenced outside of perl, we just list them as e.g. bar::baz
without a version and with a link to search.cpan.org.
All of these modules now required by ntp are currently listed as
dependencies of LWP::Protocol::https-6.06.
Net::SSLeay is a dependency of IO::Socket::SSL, arguably we could
keep it as an unversioned dependency on the perl modules page.
Mozilla::CA is currently only listed as a dependency of the protocol
module, so it really ought to be versioned. I know that biber pulls
it in, but via the protocol which is why it has not until now gained
a version in the book.
I think that (at least) Net::SSLeay and Mozilla::CA should be
promoted to full members of the book.
Does anybody disagree ?
I do. If the user can just do 'cpan -i LWP::Protocol::https', why do we
make it difficult by specifying all these different components? cpan
does build from source, so it does not really violate the spirit of
'from scratch'. It may pull in some minor components that are not
strictly required, but the speed of install vs a manual fetch and
individual install more than compensates for the small amount of extra
space used.
Specifying the specific versions also creates more work for the editors.
That said, I will go along with how the majority of editors feel on this
topic.
-- Bruce
In an ideal world, I also think that all perl modules required by
other modules in the book ought to be fully present and in
individual XML files, soemwhat like the python modules - but my last
attempt to try doing that for one example module failed to pass the
book's XML validation, so for the moment I'm not proposing to attempt
that.
ĸen
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
