#11123: Revise the organization of the perl modules.
-------------------------+-----------------------
Reporter: ken@… | Owner: ken@…
Type: enhancement | Status: assigned
Priority: normal | Milestone: 8.4
Component: BOOK | Version: SVN
Severity: normal | Resolution:
Keywords: |
-------------------------+-----------------------
Comment (by cjg):
Replying to [comment:5 ken@…]:
> Replying to [comment:2 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.
--
Ticket URL: <http://wiki.linuxfromscratch.org/blfs/ticket/11123#comment:8>
BLFS Trac <http://wiki.linuxfromscratch.org/blfs>
Beyond Linux From Scratch
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
