Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 57677 - Design: Mac OS X's perl vs. Gentoo's perl
Summary: Design: Mac OS X's perl vs. Gentoo's perl
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Mac OSX (show other bugs)
Hardware: PPC Linux
: High major (vote)
Assignee: osx porters
URL:
Whiteboard:
Keywords:
: 56859 74955 (view as bug list)
Depends on: 58931
Blocks: 56859 57853 58576 60018 60811 63597 64352 65748 73518 74958 78822 93638
  Show dependency tree
 
Reported: 2004-07-19 21:54 UTC by Saadiq Rodgers-King
Modified: 2007-03-20 21:10 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
perl-module-eclass.patch (perl-module-eclass.patch,385 bytes, patch)
2004-08-18 12:00 UTC, Robin Munn
Details | Diff
perl-module.elcass.diff (perl-module.eclass.diff,4.24 KB, patch)
2004-08-23 14:46 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff
perl-modules.eclass.diff (perl-module.eclass.diff,1.04 KB, patch)
2004-09-26 23:58 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff
updated for current perl-module.eclass (perl-module.eclass,7.36 KB, patch)
2005-08-12 10:38 UTC, Kito (RETIRED)
Details | Diff
perl-module.eclass.patch (perl-module.eclass.patch,775 bytes, patch)
2005-08-12 10:52 UTC, Kito (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Saadiq Rodgers-King 2004-07-19 21:54:20 UTC
I attempted to emerge perltidy-20031021 using gentoo-macos.  It initially failed because perltidy-20031021 was masked due to a lack of the "macos" keyword.  As the docs say, I added the "macos" keyword to the ebuild file to give it a try because I know I can compile it fine from source.  The next failure was because the deps say that it requires Perl 5.8.2 and OSX 10.3.4 only has 5.8.1 as of now.  I wasn't able to find out where to elegantly edit this dependency so I "emerge --nodeps perltidy" and it proceeded.  The compile worked fine and install worked fine with just one hitch.  It seems the binary was placed in "/usr/usr/bin/" instead of just "/usr/bin".  I'm pasting the file locations below.  The last issue was that "/usr/lib/perl5" where "Perl/Tidy.pm" was installed, wasn't in my PERL5LIB.  To temporarily get around that I edited the perltidy script to call "#!/usr/bin/perl -I/usr/lib/perl5
".  I'm not sure if the installation of perl should include that or what, but these were the list of items I noticed.  With the resolution of those things, it works fine.  Thanks.

>>> /usr/lib/perl5/
>>> /usr/lib/perl5/5.8.1/
>>> /usr/lib/perl5/5.8.1/darwin-thread-multi-2level/
>>> /usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/
>>> /usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Perl/
>>> /usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Perl/Tidy/
>>> /usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Perl/Tidy/.packlist
>>> /usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Perl/Tidy/.packlist-e
>>> /usr/lib/perl5/Perl/
>>> /usr/lib/perl5/Perl/Tidy.pm
>>> /usr/man/
>>> /usr/man/man1/
>>> /usr/man/man1/perltidy.1
>>> /usr/man/man3/
>>> /usr/man/man3/Perl::Tidy.3pm
>>> /usr/share/doc/perltidy-20031021/
>>> /usr/share/doc/perltidy-20031021/MANIFEST.gz
>>> /usr/share/doc/perltidy-20031021/README.gz
>>> /usr/share/perl/
>>> /usr/share/perl/gentoo-pods/
>>> /usr/share/perl/gentoo-pods/5.8.1/
>>> /usr/System/
>>> /usr/System/Library/
>>> /usr/System/Library/Perl/
>>> /usr/System/Library/Perl/5.8.1/
>>> /usr/System/Library/Perl/5.8.1/darwin-thread-multi-2level/
>>> /usr/System/Library/Perl/5.8.1/darwin-thread-multi-2level/perllocal.pod
>>> /usr/usr/
>>> /usr/usr/bin/
>>> /usr/usr/bin/perltidy

Reproducible: Always
Steps to Reproduce:
1. Add "macos" keyword to perltidy-20031021
2. emerge --nodeps perltidy
3.
Actual Results:  
perltidy installed in the wrong area.  "/usr/usr/bin" instead of "/usr/bin"

Expected Results:  
install the binary to "/usr/bin" and maybe warn that "/usr/lib/perl5" wasn't in the PERL5LIB path
Comment 1 Robin Munn 2004-08-18 12:00:26 UTC
Created attachment 37680 [details, diff]
perl-module-eclass.patch

This patch to /usr/portage/eclass/perl-module.eclass fixes the "install root"
problem for me when installing the XML-Parser perl module. Before this patch,
XML-Parser's files were going in places like /usr/System/Library and
/usr/usr/(foo). Now they're going into /System/Library and /usr/(foo) instead.

I have *not* tested this patch on any platforms other than macos. It may be
that the old behavior is needed on, say, x86. In that case, my change should be
enclosed in an "if [ `use macos` ]; then" block, with the "else" being the old
behavior.
Comment 2 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-08-18 22:06:51 UTC
I tested the patch and it doesn't change any behaviour on x86. However, "/usr/man/man?" is not the right place for manpages. It should be "/usr/share/man/man?". baselayout package on Gentoo Linux creates a symlink from /us/man to /usr/share/man but no such symlinks are provided by Mac OS X, and it needs to be fixed on macos side. Just FYI, "if [ `use macos` ] ; then blah blah ; fi" syntax is deprecated. Use "if use macos ; then blah blah; fi" instead. (use function will be changed to not echo USE variable in the future.)
Comment 3 Michal Suchanek 2004-08-23 08:35:54 UTC
perl 5.8.2 was probably the first perl in gentoo that could install perl modules using DESTDIR.
As the perl 5.8.1-RC3 in macos should be sufficient for that (its MakeMaker 6.12 has DESTDIR support) the dependency in perl-module eclass should be changed and perl and libperl could then be just injected to reflect the current system version.
Comment 4 Michal Suchanek 2004-08-23 10:20:12 UTC
I have another problem with perl module: ReadKey gets installed in /usr/lib, no /Library. If you think it is OT here I can file a new bug.

./
./usr/
./usr/lib/
./usr/lib/perl5/
./usr/lib/perl5/5.8.1/
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Term/
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Term/ReadKey/
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Term/ReadKey/.packlist
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Term/ReadKey/autosplit.ix
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Term/ReadKey/ReadKey.bs
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/auto/Term/ReadKey/ReadKey.bundle
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/Term/
./usr/lib/perl5/5.8.1/darwin-thread-multi-2level/Term/ReadKey.pm
./usr/man/
./usr/man/man3/
./usr/man/man3/Term::ReadKey.3pm
./usr/share/
./usr/share/doc/
./usr/share/doc/TermReadKey-2.21/
./usr/share/doc/TermReadKey-2.21/MANIFEST.gz
./usr/share/doc/TermReadKey-2.21/README.gz
./usr/share/perl/
./usr/share/perl/gentoo-pods/
./usr/share/perl/gentoo-pods/5.8.1/
./usr/System/
./usr/System/Library/
./usr/System/Library/Perl/
./usr/System/Library/Perl/5.8.1/
./usr/System/Library/Perl/5.8.1/darwin-thread-multi-2level/
./usr/System/Library/Perl/5.8.1/darwin-thread-multi-2level/perllocal.pod
Comment 5 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-08-23 10:30:38 UTC
TermReadKey is another issue. It will need modifying TermReadKey ebuild in addition to perl-module.eclass. ("/usr" seems to be hardcoded in the ebuild) Please open another bug for that.
Comment 6 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-08-23 14:44:32 UTC
I couldn't find a solution to use vendor dir for perl modules on Mac OS X. perl-module.eclass sets installdirs=vendor, which results in packages installed into /Network/Library/Perl/5.8.1/... (/Network is not writable so emerge any perl module will fail). I suggest that perl modules on Mac OS X use installdirs=site. In doing so, perl modules are installed to /Library/Perl/5.8.1/... and perl modules are installed successfully. What do you perl herd members think? 

Also I changed DEPEND to "!macos? ( >=dev-lang/perl-5.8.2 ) macos? ( >=dev-lang/perl-5.8.1 ) !<dev-perl/ExtUtils-MakeMaker-6.17" to not pull in Portage's perl (it will overwrite Mac OS X's system perl).

I'll attach a patch. Tested on several packages including XML-Parser, TermReadKey and so on. If there is no objection I'll apply the patch to CVS. 
Comment 7 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-08-23 14:46:50 UTC
Created attachment 38052 [details, diff]
perl-module.elcass.diff
Comment 8 Lina Pezzella (RETIRED) gentoo-dev 2004-08-23 14:55:25 UTC
I object.  <snip>Also I changed DEPEND to "!macos? ( >=dev-lang/perl-5.8.2 ) macos? ( >=dev-lang/perl-5.8.1 ) !<dev-perl/ExtUtils-MakeMaker-6.17</snip>  Why did ExtUtils-MakeMaker require perl >= 5.8.2 in the first place?  Without looking at any code or asking any people, I would guess that it has something to do with Gentoo's @INC reversal, in which case, I think we should have a meeting on whether or not we want to install a gentoo version of perl alongside the macos version, or if we want to try to "fix" all of the modules.  In any case, unless the reason for requiring >=dev-lang/perl-5.8.2 is trivial (in which case perhaps the DEPEND should be changed entirely), I don't think we should be making any large changes until it has been discussed with the entire team.
Comment 9 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-08-24 02:01:17 UTC
All right, I leave it to the next meeting. If we decide to install
Gentoo version of perl, this change (vendor => site) will be
unnecessary.

Well, I investigated more. What I can see from perl-modules.eclass's
ChangeLog and bugs, it should block <dev-perl/ExtUtils-MakeMaker-6.11.
I guess the reason why it requires 5.8.2 is that 5.8.1 and 5.8.1-r1 in
Portage were never marked stable (perhaps due to the version number?).
Eclasses doesn't have version number so it is fair enough to force
stable version of perl to upgrade. If so, it seems ok to change the
deps to 5.8.1 because at least perl 5.8.1-RC3 has MakeMaker 6.12. (We
needn't change DEPEND to what I wrote, just
DEPEND=">=dev-lang/perl-5.8.1 !<dev-perl/ExtUtils-MakeMaker-6.11"
would suffice.)
Comment 10 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-09-25 22:55:28 UTC
*** Bug 56859 has been marked as a duplicate of this bug. ***
Comment 11 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-09-26 23:58:15 UTC
Created attachment 40515 [details, diff]
perl-modules.eclass.diff

Modified to recognise new ppc-macos keyword.
Comment 12 Hasan Khalil (RETIRED) gentoo-dev 2004-10-03 02:41:53 UTC
have you taken a look at the reversal of @INC in perl?

if not, please do.

if so, how can you say that macos' perl would be the
same as gentoo's perl >=5.8.2? i must be missing
something if this is the case. (i often miss many things)

see http://www.gentoo.org/news/en/gwn/20030728-newsletter.xml
for details.
Comment 13 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-05 03:41:14 UTC
gongloo: thanks for pointing that. I couldn't find that document by myself.
Now I understand what you were talking about. One solution to that problem
is to insert /etc/env.d/40perlinc (or whatever) which defines PERLLIB to what
we like. The current Mac OS X installer doesn't process env.d scripts at all,
but env.d scripts need to be loaded in order for Portage packages to work.
This might need some work because Mac OS X's /etc/profile is not what we
have in Gentoo Linux, but not that hard I assume.
Comment 14 Michael Cummings (RETIRED) gentoo-dev 2004-10-05 17:12:53 UTC
As rac explained in irc with gongloo: The perl herd can not support any changes that allow for a non-Gentoo installed perl to be used. If it isn't installed by Gentoo, we have no accountability for its functionality, interoperability, or support. We will not modify the eclass or any perl modules for a non-gentoo installed perl. We cannot provide support (bug-wise) for that - there are too many factors involved to be able to cover it. 
Comment 15 Lina Pezzella (RETIRED) gentoo-dev 2004-10-06 09:14:05 UTC
The ppc-macos group has yet to agree upon what to do with the perl issue. We certainly haven't agreed to modify things to use the MacOSX perl. The @inc reversal was done for a reason, and since MacOS doesn't have it, it's unacceptable to me to use their perl. Possible solutions that I see involve doing something like <g>perl like we did to solve the sed issue. Of course this brings up all sorts of difficulties with libraries that weren't an issue with sed. The other possibility is to wait for pathspec and not support installing perl to / at all. A third possibility is to get details on what was done with the @inc reversal, and to see if an emulation of this is possible with MacOS's perl. I don't claim to know much about the backend of perl -- can someone from the perl herd point me to exactly what had to change in order to reverse @INC codewise?
Comment 16 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-06 11:46:27 UTC
I'd prefer the third option now, but if it's not acceptable by perl 
herd, I'd rather choice the second (wait until pathspec is done).
However, there are dozens of packages, including gtk+,  
that need perl-modules.eclass and I cannot push other osx
devs to do so. 

dev-lang/perl/files/perl-*-reorder-INC.patch is doing @INC 
reversal, so we more or less need to compile perl to achive this.
I modified dev-lang/ruby and app-editors/emacs to coexist
with Mac OS X's ones (both are now SLOT'ed), so if we could
add SLOT support to perl then it could be solved. (we can put
alias perl=perl-5.8.x to profile.bashrc in our profile, can't we?)
Comment 17 Lina Pezzella (RETIRED) gentoo-dev 2004-10-06 13:35:38 UTC
Slotting works for me, but since I am not the person doing the work, I really cant do much than vote. If there is no desire to put in the work required for slotting perl, I agree that the most sane alternative is to wait for pathspec.
Comment 18 Hasan Khalil (RETIRED) gentoo-dev 2004-10-06 13:37:18 UTC
I'm all for the slotting idea. I admit, though, that I haven't even
looked at how difficult/easy that may be. It seems to me to really
be up to the perl herd for that one -- if they'll accept slotting perl
as an option, that is.
Comment 19 Michael Cummings (RETIRED) gentoo-dev 2004-10-06 14:26:22 UTC
(Is this really the right bug for this discussion?)
We have played with slotted perl in the past, but because of issues related to libperl (iirc) it wasn't a feasible option. 

@INC reversal will require you to recompile with the supplied patches.

If you're recompiling perl to begin with, why not get a newer version (say, one with an ebuild...) working?

In which case the entire thread is moot - because you would have a gentoo installed perl, and everyone would be happy :)
Comment 20 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-06 23:55:23 UTC
One of the best things I like in Gentoo is the freedom of choice; 
if all users don't care overwriting system perl, that's ok
(we are discussing using ppc-darwin for those users), but if there
are a number of people who don't want to overwrite system perl, 
it's better to provide an option for that.
Comment 21 Joe Jezak (RETIRED) gentoo-dev 2004-10-07 00:33:26 UTC
The patches to the 5.8.4 ebuilds that are required to build perl on MacOSX are available in bug 58931.  I'll take the responsibility of updating these fixes for 5.8.5 if the idea seems sound.  I realize that the patches are a little old (they were written pretty early on) but hopefully they will help.

We do need to come up with a solution that doesn't involve pathspec as pathspec should not be a requirement.
Comment 22 Lina Pezzella (RETIRED) gentoo-dev 2004-10-07 12:00:35 UTC
In response to Comment #21, these patches allow one to build "Gentoo Perl" on MacOS with some magic so that both Apple's perl and Gentoo's perl can coexist peacefully? If this is the case, then please summarize for those of us here that don't know what the directory structure is and how the system decides which version of perl to use. If not, then this patch doesn't adequately solve the problem yet.
Comment 23 Michael Cummings (RETIRED) gentoo-dev 2004-10-07 13:24:11 UTC
Gentoo's freedom of choice isn't at issue here. We don't and can't support users who compile their own brand of perl on x86; we can't do that here either. Perl herd has approximately 85+ open bugs right now, down from 109 a few weeks ago but still - we have enough issues and bugs to deal with with individuals using a gentoo perl. If you know of a solution that allows gentoo's and mac's perl to coexist - awesome, bring it on. But we can't be expected to support bugs introduced by using a perl packaged by Apple and forced into a gentoo-ified system. Not fair to Apple, not fair to us.

Yea, someone will hopefully talk to me on irc one day and realize I do more than just rant :)
Comment 24 Joe Jezak (RETIRED) gentoo-dev 2004-10-07 22:07:00 UTC
In response to comment #22, the patches in 58931 allow gentoo's libperl and perl to be built on OSX.  They are not a complete fix, in that they only allow compilation and don't resolve the perl issue, but they are a needed step in solving this problem.

After these have been applied, libperl compiles correctly and installs cleanly.  Perl is blocked by the existing man pages and the perl binaries in /usr/bin.  I'll attach the list the list of files that would be overwritten on bug 58931, along with new unified diffs of the fix against the same version of perl (5.8.4).
Comment 25 Joe Jezak (RETIRED) gentoo-dev 2004-10-12 11:10:30 UTC
Since the only thing blocking the install are the binaries and man pages, maybe we could write a "perl-config" program that lets the user select which version (Apple or Gentoo) to use, that simply simlinks in the correct files (like a gcc-config for perl maybe?).
Comment 26 Wout Mertens (RETIRED) gentoo-dev 2004-10-25 01:50:43 UTC
Ok, so we have 2 problems:

Problem 1: Perl-module eclass installs install into /usr, where it's not found by Perl.

  - Solution: remove PREFIX=/usr -> installs into /Network, the vendor dir.
     This follows the reasoning of the document mentioned in #12.

This seems to be the only solution for this problem, and it is independant of the next problem.
Therefore I think the latest diff should leave the install into the vendor dir, and it should go in
the tree.

It does create the /Network directory, and that's just something that users will have to live with.

Problem 2: Apple's perl doesn't do @INC reversal.

  - Solution 1: Ignore. This is for those who don't want to mess with their system perl install.
     Just make sure perl-module-eclass is happy with perl-5.8.1, and you're good to go.
    You will run into the problems that made Gentoo decide to go with path reversal though.

  - Solution 2: Compile Gentoo's perl, with the correct paths in the reversed order.

This is a user choice, and it is made by either upgrading or not upgrading to the latest perl.
It has no impact on the previous problem, which is the only problem covered by this bug.

BTW, this is the default @INC:
    /System/Library/Perl/5.8.1/darwin-thread-multi-2level
    /System/Library/Perl/5.8.1
    /Library/Perl/5.8.1/darwin-thread-multi-2level
    /Library/Perl/5.8.1
    /Library/Perl
    /Network/Library/Perl/5.8.1/darwin-thread-multi-2level
    /Network/Library/Perl/5.8.1
    /Network/Library/Perl
    .
Comment 27 Wout Mertens (RETIRED) gentoo-dev 2004-10-25 03:18:31 UTC
Argh, I just noted that /Network is not for writing. Sigh.

So that means that the current .diff is the only solution. Users won't be able to install perl modules that override Gentoo perl modules though.

A possible solution is to augment the Gentoo-perl @INC with /usr/local/lib/perl, so the user can install in there.
Comment 28 Take Vos 2004-12-19 11:24:06 UTC
*** Bug 74955 has been marked as a duplicate of this bug. ***
Comment 29 Michal Suchanek 2005-03-14 08:46:45 UTC
Is anybody planning to fix this?
This is critical for making the portage system usable, unfortunately there are many packages that require perl modules.

As it is now, I can install XML-Parser and the gtk+ 1.2 package that requires it builds.
However, it needs fixing the perlmodule eclass to require only perl 5.8.1 (or using --nodeps or something), and there is a conflicting file /usr/System/Library/Perl/5.8.1/darwin-thread-multi-2level/perllocal.pod.

The perllocal probably comes from Term-Readline or somesuch.

The files appear to install in a sane place:
/usr/lib/perl5/5.8.1/darwin-thread-multi-2level/XML/Parser.pm
/usr/man/man3/XML::Parser::Style::Objects.3pm
/usr/share/doc/XML-Parser-2.34/MANIFEST.gz
/usr/share/perl/gentoo-pods/5.8.1
Comment 30 Michael Cummings (RETIRED) gentoo-dev 2005-07-19 08:11:04 UTC
(In reply to comment #26)
> Problem 2: Apple's perl doesn't do @INC reversal.
> 
>   - Solution 1: Ignore. This is for those who don't want to mess with their
system perl install.
>      Just make sure perl-module-eclass is happy with perl-5.8.1, and you're
good to go.
>     You will run into the problems that made Gentoo decide to go with path
reversal though.
[piping up] which, as a reminder, is that if you install a perl module that
supercedes one shipped with your core perl install (and @INC isn't reversed),
you either face collision because your overwriting the perl-installed version,
or the module will be unavailable because the core one will show up in @INC
first and get invoked ahead of the one you just emerged.

>   - Solution 2: Compile Gentoo's perl, with the correct paths in the reversed
order.

I hate to be a pain here (honestly, I do) - but this is the only way the perl
herd is going to be able to assist any macos users that have problems with the
perl related installs. If you want to forgo any support for perl in macos, you
can ignore solution 2.

Any solution reached at all that involves changes to the eclass or the ebuilds
for *perl* (dev-perl* and dev-lang/perl*) should be passed through a perl herd
member though (only bringing that up because of comments about just committing
changes to the tree to correct for problems). I recognize that the macos
following is huge - but we have a pre-existing userbase for the other platforms
that I need to watch out for :)
Comment 31 Joe Jezak (RETIRED) gentoo-dev 2005-07-19 09:15:26 UTC
Here's what we're thinking about doing (and why bug #58931 was reopened).  Since
we now support a "progressive" profile in which existing OSX files are
overwritten.  This means that we can use Gentoo's perl which is far preferable
to the previous situation.  To get this working, we would need to patch the perl
ebuilds as in bug #58931 and use the eclass fix as provided here.  For the perl
ebuilds, I'm currently looking at implementing something like a get_lib_version
to fix the .so.1/.1.dylib issue (perhaps in multilib?) so that we don't have to
use the variables as in the previous solution for bug #58931.  I will definitely
ask before making any changes, so no worries. :)
Comment 32 Kito (RETIRED) gentoo-dev 2005-08-12 10:38:13 UTC
Created attachment 65775 [details, diff]
updated for current perl-module.eclass

Fixes install locations for Darwin/OS X
Comment 33 Kito (RETIRED) gentoo-dev 2005-08-12 10:52:09 UTC
Created attachment 65776 [details, diff]
perl-module.eclass.patch

I suppose the actual patch would help :p
Comment 34 Fabian Groffen gentoo-dev 2007-03-20 21:10:39 UTC
with prefix compiled perl, emerging other perl packages goes without trouble as far as I know.