On Fri, Mar 23, 2018 at 10:22:07PM +0100, Pierre Labastie wrote:
On 23/03/2018 21:26, Bruce Dubbs wrote:
On 03/23/2018 02:56 PM, Ken Moffat wrote:
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.
I seem to have ended up doing many changes in the perl modules page,
but only because I ended up looking after TeX Live - the perl
modules in the dependency tree for biber seem to breed like rabbits.
Before that, the perl modules were fewer, but they still had the
same approach - show a module, with its required dependencies and
the dependencies needed for the testsuite.
And I had understood that the rule for what went into the book was
"if a package in the book requires something, that too should be in
the book".
An aside comment for the little it is worth: I'm probably only going
to build ntp on those builds which are not virtual and are on
machines which can neither hibernate nor suspend - chrony seems to
work much better in those situations (only really tested re s2ram so
far, but the time seems to get back in sync within a minute of waking
up instead of sometimes becoming too far adrift to recover).
Specifying the specific versions also creates more work for the editors.
Because of the way that dependencies multiply, I would prefer to
list "known good" versions with their dependencies. And yes, other
changes in LFS or (occasionally) other parts of BLFS sometimes break
the tests - usually, by the time I update the versions I'm using
somebody else has found the problem and there is a new release of
that module.
The alternative you appear to be proposing (based on what I
proposed) is to throw away the details of module dependencies and
replace each link to a versioned module with a link to cpan.
That said, I will go along with how the majority of editors feel on this topic.
Actually, newer build systems (cargo, maven) pull in dependencies when they
need to. So does "python setup.py". Not more not less than cpan -i. The
drawback is that the user looses control on what he or she installs. The
advantage is that the user does not need to script the build of tons of
dependencies just for installing one package.
It's the loss of control which bothers me. When we added pip to
python (we had to, no argument about that) it was the thin end of
the wedge. From time to time I review which python3 modules get
pulled in by the modules I build, and make a decision on whether or
not to build them manually (and therefore fix a version for a few
months). Unlike *released* perl5 modules, the python module
infrastructure is generally very variable (e.g. modules where only a
beta is available and the tarred or zipped source for previous
versions is no longer available : I've seen that in the past year,
but when I checked just before 8.2-rc there weren't any modules like
that in those I needed, so perhaps the developers have improved [
hollow laugh ].
I'm not sure what to say. If we do that for perl and python modules, why not
do that for other build systems? libreoffice (a few tens of downloaded
tarballs), rust (around 200 "crates" are downloaded during the build. Those
are versioned and could be listed in a rust page). Same for maven. I think
that for maven + junit + fop, the number of "artifacts" downloaded is close to
300. In that last case, what is downloaded is "binaries" (java archives of
bytecode files).
For LO I used to save the downloads for a new version when I first
built it, but with the changes in *how* we build it that fell out.
And therefore from time to time I leave it building overnight, and
it fails because the download site is doing housekeeping or backups
and temporarily not offering a file.
For rustc, I'm dubious about the practicality of trying to
separately download crates.
As you may have noticed, I have no opinion on the various things
needed for java (I only ever build any of them to test the book).
Clearly we do not have enough resources for maintaining pages with individual
packages, or even pages with list of packages, unless we find some way of
automating the process. For example, for perl, run cpan with the appropriate
option(s) to find the dependencies, and write a program for transforming that
into docbook text...
The spirit of the book is to let the user control each bit of his or her
installations. Using cpan -i or other build systems is therefore somewhat
against the spirit of the book. OTOH, with no more that half a dozen editors,
I do not think we have the resources for reliably write all the details, and
maintain their accuracy. Ken is doing an amazingly good job for perl modules,
python modules seem to be correctly maintained, but when going to rust,
libreoffice, or maven, we stop anyway...
Thanks, but I'm only looking at those perl modules I use - I think
there is maybe one which I only build for a new server build (ISTR
SpamAssassin needs one module which is in the book but which I do
not otherwise build, as well as several other modules not in the
book - but I'm thinking about dropping SpamAssassin from my builds
because nowadays it catches very little).
Finally, writing all this made my mind: if an editor agrees to maintain the
page, it is better for the book, but we should not force him to do that, when
he wants to stop...
I'm reluctant to throw away what we and our predecessors have put
together, unless it is no-longer useful.
