On 23/03/2018 22:22, Pierre Labastie wrote: > On 23/03/2018 21:26, Bruce Dubbs wrote: >> 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. >> > > 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. > > 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). > > 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... > > 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... >
EDIT: the last part of the sentence should be: but if nobody wants to do it, let's live without it... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
