Revise the organization of the perl modules.

[ken@…]

The perl modules page is all-but unmaintainable in its current form, and in particular the XML is deeply nested, making it hard to ensure that an added dependency goes in the right place.

I was going to say that the situation had got worse after biber came into the book, but while that has greatly extended the number of modules, it has not materially worsened the page. Looking at our museum, in 6.2.0 we had a lot of external modules (but versioned, as we are now again doing), but at that time we did not list where the links were pointing to.

Indexing in longindex.html is also sub-par (current versions not shown).

To simplify this, I am proposing to create two pages - one for those modules which are referenced from the rest of the book, and a second for the modules which are dependencies of other modules but not otherwise referenced in the book.

I'm working from what we have for the Python modules, but cut down - link to our standard build and install options, only show http download and md5sum, and only mention the contents if something is installed outside of the perl directories (so the same as what we now show, but with added md5sums for the modules not referenced by other packages, and with better indexing.

Pierre tells me jhalfs will need to be adapted for this, so this will happen in a new branch.

I have also suggested listing all the dependencies for each module - this might cause problems in jhalfs, we will have to see.

[christopher]

Hello Ken,

As you are looking at the perl modules, perhaps you would also care to update the instructions regarding using cpan.

The current information is no longer correct. It says that the downloaded modules installation directories are automatically deleted. This is most certainly not the case anymore. I have done multiple installations from scratch over the past several months and none of the source directories are deleted.

Also there is the option to run cpan as a normal user using sudo to install the modules. I ran into an issue with DATETIME (from memory without actually looking at that page whilst commenting here.) that one of the submodules developers made it a requirement that one of the testing programs be run as a normal user, and did not bother to document it, instead producing a weird error and bailing on installation due to a failed test. Having this listed in the book would ensure that the do not install as root is maintained within perl modules being installed via cpan, and would eliminate the error once and for all.

Christopher.

[Bruce Dubbs]

I can confirm that the build directories are not removed. I have done a complete install (all modules in the book) and have 168 subdirectories in the build/ directory. The total space used is 286M.

In addition the statement "You may still need to install dependent library packages before running the automated installation method." is not correct. I have not needed to do that. I do not remember ever needing to do it.

I know of three issues with using the cpan installation method:

libxml2 must be installed before XML::LibXML  -- documented
libxslt must be installed before XML::LibXSLT -- documented
SGMLSpm must be installed using the standard installation method using Build.PL:
   perl Build.PL && ./Build && sudo ./Build install

I'll note that using the cpan method tasks me about 30 minutes to install all modules in the book even without scripting. (I probably ought to do that.)

[ken@…]

Replying to bdubbs:

In addition the statement "You may still need to install dependent library packages before running the automated installation method." is not correct. I have not needed to do that. I do not remember ever needing to do it.

I know of three issues with using the cpan installation method:

libxml2 must be installed before XML::LibXML  -- documented
libxslt must be installed before XML::LibXSLT -- documented
SGMLSpm must be installed using the standard installation method using Build.PL:
   perl Build.PL && ./Build && sudo ./Build install

I'll note that using the cpan method tasks me about 30 minutes to install all modules in the book even without scripting. (I probably ought to do that.)

My understanding of the current text is "You will need to install any required non-perl library packages" i.e. libxml2 and libxslt." I assumed may' was used because some people will have already installed those libs. I suspect perl-glib might have been involved too.

[ken@…]

Replying to cjg:

Hello Ken,

[only replying to this part for the moment]

Also there is the option to run cpan as a normal user using sudo to install the modules. I ran into an issue with DATETIME (from memory without actually looking at that page whilst commenting here.) that one of the submodules developers made it a requirement that one of the testing programs be run as a normal user, and did not bother to document it, instead producing a weird error and bailing on installation due to a failed test. Having this listed in the book would ensure that the do not install as root is maintained within perl modules being installed via cpan, and would eliminate the error once and for all.

Whenever I have updated biber, I have been root for my scripted build, tests, and install. I do not remember any tests run as root causing 'make test' to return an error. But it is possible that a random version of one of the modules would do that, and that a later version had been fixed.

The problem with cpan is that you get the latest releases marked as stable. Like every other package, bugs happen.

[Bruce Dubbs]

Replying to ken@…:

The problem with cpan is that you get the latest releases marked as stable. Like every other package, bugs happen.

If you are paying attention while using cpan, you can see if the installed package matches the version in BLFS.

Replying to ken@…:

My understanding of the current text is "You will need to install any required non-perl library packages"

OK, so lets change it to that.

[ken@…]

Replying to bdubbs:

Replying to ken@…:

The problem with cpan is that you get the latest releases marked as stable. Like every other package, bugs happen.

My understanding of the current text is "You will need to install any required non-perl library packages"

OK, so lets change it to that.

Will do this in the perl-modules branch, as well as experimenting with rewording the cpan instructions. I'm increasingly reluctant to change things in the old page, it takes too much time when new issues are creeping out - e.g. xfconf apparently mentions gtk2-perl as optional via a sourceforge link but also mentioning the cpan instructions.

For SGMLSpm a manual Makefile.PL build works (with the sed), if cpan wants to install Module::Build first, that ain't my problem ;-)

[christopher]

Replying to ken@…:

Replying to cjg:

Hello Ken,

[only replying to this part for the moment]

Also there is the option to run cpan as a normal user using sudo to install the modules. I ran into an issue with DATETIME (from memory without actually looking at that page whilst commenting here.) that one of the submodules developers made it a requirement that one of the testing programs be run as a normal user, and did not bother to document it, instead producing a weird error and bailing on installation due to a failed test. Having this listed in the book would ensure that the do not install as root is maintained within perl modules being installed via cpan, and would eliminate the error once and for all.

Whenever I have updated biber, I have been root for my scripted build, tests, and install. I do not remember any tests run as root causing 'make test' to return an error. But it is possible that a random version of one of the modules would do that, and that a later version had been fixed.

The problem with cpan is that you get the latest releases marked as stable. Like every other package, bugs happen.

Hello Ken,

This issue regarding the testing of the module requireing it to be run as a non root user only came up in the last couple of months. I had to google the error and it was confirmed by several people from other distros. After the failure in cpan to build the module, I downloaded the module and attempted a manual installation as per book instructions using root for the extraction and make command and it failed. It was then that I went to google and found confirmation. The thing is, to me saying that bugs happen is a total cop-out. I have used cpan way before even moving to linux from scratch, and this is the first time I have ever run into the problem of a test actually requireing to be run as non-root. Also for completeness, adding that cpan can be used as non-root is valid. The wording in the book can be interpreted that you can only use cpan as root, which is not the case. They have the option within cpan shell when it is first run as a non-root user to have it run using sudo, so why not have it added to the instructions?

Yes bugs do happen, but my point is 100% valid. Who is to say that more of the perl module developers will require that the tests be run as non-root? I can even go further and state that the KDE developers have forcefully made it in their code that root can not run kde. Developers need to realise that they do not own the hardware things are being run on. For people installing in a commercial environment it is up to the computer code of conduct/acceptable practices. For the home user it is their own property.

[ken@…]

CPAN instructions modified in the branch in r20498. Rendered versions not pushed out until I've made more progress on updating some modules.

[ken@…]

Some further changes in the wording, and more modules added. Sync'd to trunk at r20501, rendered versions at ​http://www.linuxfromscratch.org/~ken/perl-changes/

[ken@…]

Merge of branch completed in r20714