Re: [gentoo-osx] env.d; perl with collision-protect

[Finn Thain]

On Thu, 18 Aug 2005, Hasan Khalil wrote:

> The Background:
>
> Perl is almost ready for the default (collision-protect) profiles. I've
> modified the latest perl ebuild to install all binaries (normally
> installed to '/usr/bin') into another location
> (/System/Library/Perl/${PV}/bin) to avoid collisions. No other
> collisions are created by the perl ebuild. I'll make these revisions
> more public once I can get them tested more thoroughly (I already broke
> Apple's perl on my system, accidentally of course, while working on
> Gentoo's perl). There are still a few issues to iron out.

Nice work!

> The Issue at Hand:
>
> One of these issues is providing Gentoo's perl as the default when
> `perl` is executed in interactive shells (bash, in my case). The lovely
> '/etc/env.d' structure lends itself to the sort of PATH mangling that
> needs to be done, but there is one problem here. '/etc/profile.gentoo'
> appends the PATH from '/etc/profile.env' to the existing PATH, rather
> than inserting to the beginning of the existing PATH.

This is consistent with the intent of collision-protect. People (users, 
ISVs) care about the behaviour of Apple's OS X. That is, they care about 
avoiding collisions in the file system only in as much it preserves that 
behaviour.

> This is not just an issue with perl, but also with any other program
> that we install to a different prefix and that is also provided by Apple
> in the default PATH (later down the line we should have prefixable
> installs globally supported by portage 2.1).
>
> My Proposed Solution:
>
> I'm thinking that we should have a variable (perhaps in some file in
> '/etc/conf.d', or perhaps just in /etc/profile before the line that
> sources '/etc/profile.gentoo') that dictates whether or not the
> '/etc/profile.env' PATH should take precedence over the default PATH.
> All that needs to be done then is to check for this variable in
> '/etc/profile.gentoo' and export the PATH appropriately. Of course, one
> of the most important things to do would be to document this (both in
> the revised baselayout's post-install message, as well as on the web
> somewhere).

I think this is potentially confusing (for some), since you can now have 
FEATURES saying preserve behaviour yet have a variable saying the 
opposite.

Thing is, those people who don't like to change the behaviour of their OS 
X system will not put Gentoo perl early in the PATH anyway. And if they 
need Gentoo perl as a dep, then they need a prefixed install.

So, the easy answer is, let Gentoo's perl overwrite the OS X perl 
binaries.

People running collision-protect can just remove that FEATURE for perl 
(i.e. emerge --onlydeps with collision-protect, then emerge perl without).

If you take this point of view, it becomes a question of, "how good is 
Apple's perl at satisfying deps?". If perl can't be effectively 
package.provided, then the compromise above may not be good enough for 
those who want both the perl dep and apple's behaviour, and yet can't wait 
for prefixed installs... Well, I think that is asking too much. I don't 
think adding potentially conflicting variables is a good response to such 
demands. I guess it depends on how broken apple's perl is.

Also, I would caution you against making compromises that will be 
inappropriate once prefixed installs are available. Compromises in that 
direction will only have to be undone later. ebuilds that do tricks to 
avoid collisions will become problems later (for example, imagine you are 
building stuff under Gentoo/Darwin, and there is no #!/usr/bin/perl, for 
example, because it was installed in /System/Library/Perl/5.8.6/bin/perl)

-f

> What does everyone think?
>
> --
> Hasan Khalil
> eBuild and Porting Co-Lead
> Gentoo for Mac OS X
>
>
-- 
gentoo-osx@g.o mailing list