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
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.
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.)
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.
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
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.
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.
Created attachment 38052 [details, diff] perl-module.elcass.diff
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.
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.)
*** Bug 56859 has been marked as a duplicate of this bug. ***
Created attachment 40515 [details, diff] perl-modules.eclass.diff Modified to recognise new ppc-macos keyword.
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.
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.
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.
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?
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?)
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.
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.
(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 :)
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.
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.
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.
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 :)
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).
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?).
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 .
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.
*** Bug 74955 has been marked as a duplicate of this bug. ***
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
(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 :)
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. :)
Created attachment 65775 [details, diff] updated for current perl-module.eclass Fixes install locations for Darwin/OS X
Created attachment 65776 [details, diff] perl-module.eclass.patch I suppose the actual patch would help :p
with prefix compiled perl, emerging other perl packages goes without trouble as far as I know.
