On 08/26/2018 08:56 PM, Ken Moffat wrote:
I'm just about to "promote" IO::Socket::SSL and "HTTP::Daemon" to
full members of the book. The reason is that their use by wget
matches Bind's use of Net::DNS which is already fully in the book.
For the future, I'm going to suggest that we do not, as a matter of
course, update perl module versions (and therefore, do not search
daily for new versions). Some of these modules rarely change, but
others change their dependencies every few months - unless there is
a *need* to update (for what I deal with, biber is the usual cause
of that, but vulnerabilities sometimes happen and new perl releases
can break some moduls), I suggest that we keep static versions until
nearer to a release.
Once the dust has settled on 8.3, I hope to have another go at
trying to make the structure of the perl modules more like what we
do for python modules (one page for all modules, pulling in a file
for each) - the difference will be that there are so many that
they'll need their own subdirectory.
The purpose of that is to make maintaining them a lot easier (the
current XML is close to unmanageable), by creating a separate file
for every mentioned module. That will have the side-effect of
making dependency documentation easier to follow.
I know that Bruce doesn't believe in manually building the modules
when he can use cpan, but some of our users, me included, want
toknow about the dependencies.
You know that cpan fetches the sources, checks dependencies, builds the
packages and runs the tests, right? The difference is that the process
is handled by cpan and automated. At the end, I have all the source
tarballs that were used to build the modules.
It's not like just fetching already built *.pm files.
In a lot of ways cpan is a lot like jhalfs.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
