In fact, it is included but under /usr/bin/perlbin/*/*
that is just... crazy!

Is this being changed to the standard way (/usr/bin) or should I start installing Perl by hand? :-S

By the way, perl-5.10.0-2 was just perfect.
I have it installed in a virtual machine, and working very well.

I've seen the Perl Policy page on the wiki.
It would be great if who took that decisions were a Perl developer. At least, a Perl Module writer.

If the configure script makes it able to separate vendor/site/etc does not mean that it is the preferred way.
In fact, if you just accept the default decisions in the Perl configure script you will get a better package (IMHO).

At the moment I just removed all perl modules (--nodeps) and I am installing it by hand, as my job requires Perl.

Cheers
ambs

The bin directories are a little odd but the idea is to be able to install perl with standard modules, a module package, or a module via CPAN without file conflicts (and without using pacman --force). For example three installations of Archive::Tar.

I believe that the original policy writer was a Perl developer but he has disappeared. But everything still works as before just in different locations. Unless you can explain an actual usage problem besides "I don't like it" and "I'm better than you" then I'll just close this bug.

HI

First let me assure you this is not a "I-m better than you" issue.
That I do not like it, it is true.

Why I am sure this is a bad idea: because nobody uses this kind of
organization.
If you look at every distribution, being it a linux, windows, mac or
unix, they all put the binaries under /usr/bin.

More, if you look into the configure script for Perl, it suggest doing
that. It wasn't done by me. It was done by somebody that knows more of
Perl than both of us, I am sure.

Also, to have different binaries for the same module means having
different modules installed. And it is a headache to develop in Perl
with that kind of system. If you do not want to trust me, you are in
your right. But I work for Perl for about 10 years and I had a lot of
trouble with that kind of decisions.

Finally, if you just close the bug, at least fix the search path for
binaries. If things were working "as before" I wound't have noticed.
:)

Cheers
ambs

I believe the basic idea was that between official perl releases the modules in the standard library do not get updated. So the perl package would contain say Sys::Syslog 0.10. So some people decided to create a perl repository that would contain packages for updates: perl-sys-syslog 0.20. Except that this had file conflicts with the perl package. If a user upgraded Syslog on their own using CPAN an installation of perl-sys-syslog or perl would fail with conflicts.

I'm not sure what you mean by "fix the search path" since /etc/profile.d/perlbin.sh would have setup the paths properly and all binaries would be accessible. That is you still haven't identified any breakage.

Hello again, Kevin

Yes, I understand that. But it doesn't solve the problem either. Say, I updated that module manually to version 0.20. Some time later, I install a package from Arch that requires version 0.21. pacman will install version 0.21 on the vendor directory and the software I installed that depends on it will not work. I think it is better to give conflicts, as it will warn the user that there is something wrong and it will not work.

I mean, if the user knows how to install Perl modules manually, he will know how to solve the conflicts problems when installing a package over it.

Regarding the search path: probably it was my fault.
Probably I didn't logout/login after updating the perl package and before trying to use cpan. (oops)

Cheers
ambs

Hi, Kevin.

Long time from our last messages, and the fourth build is out.
Although I do not agree with the decisions, it seems that I am the only one.
So, be free to close the ticket if the package will not change.

Cheers
ambs