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... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
