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

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

[Hasan Khalil]

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

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.

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 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).

What does everyone think?

--
Hasan Khalil
eBuild and Porting Co-Lead
Gentoo for Mac OS X


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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@gentoo.org mailing list

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

[Grobian]

On Fri, August 19, 2005 06:13, Finn Thain wrote:
> Nice work!
Indeed!

>> ... '/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.

I tend to disagree here.  A user who installs Portage eh.. Gentoo for OSX
knows how to use a shell (Terminal.app) and uses portage to be able to use
those commands from his/her shell.  We don't provide any (crappy) visual
oriented tool like FinkCommander, so if you are scared of a prompt, you
better look for something else.  Since this perl install doesn't touch any
of Apple's files, and this install would typically only be 'activated' in
a shell, normal OSX applications would keep on using the OSX perl, while
the shell applications would use the Gentoo perl.  I think this is what
the user meant when (s)he was emerging perl.  With a prefix this won't be
any different IMHO.

>> 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.
>
> I think this is potentially confusing (for some), since you can now have
> FEATURES saying preserve behaviour yet have a variable saying the
> opposite.

Hmmm, the idea of pre/post fixing on the path is a bit messy, but I can't
think of anything better.  Though I would think that anything you install
using portage would have a preference over the OS provided stuff, if I
follow my own reasoning as above.
I don't agree that FEATURES="collision-protect" means "preserve
behaviour", it means "don't screw up my system, make sure I can get back
to normal if I want to".  Maybe it's just a todo to make this viewpoint
clear somewhere.

> 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.

If you don't want to change the behaviour of your OSX machine, you
shouldn't install portage, fink, or whatsoever, because by adding software
you change it's behaviour.  (It normally would say: "command not found")

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

What if some nifty app depends on Apple's perl?  Sounds not like a good
plan, IMHO.

> 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.

Agreed, it is a workaround, but due to its setup it feels to me like an
early pilot to see how a prefixed install will be manageable...

> 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)

Again agreed, but having a pilot is an attractive thing to me.  It makes
us able to think about and experience the things we have to deal with when
prefixed installs become available.

-- 
gentoo-osx@gentoo.org mailing list

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

[Finn Thain]

On Fri, 19 Aug 2005, Grobian wrote:

[snip]

> Though I would think that anything you install using portage would have 
> a preference over the OS provided stuff, if I follow my own reasoning as 
> above.

I see your point, but I still think it is a rather gray area.

> I don't agree that FEATURES="collision-protect" means "preserve 
> behaviour", it means "don't screw up my system, make sure I can get back 
> to normal if I want to".  Maybe it's just a todo to make this viewpoint 
> clear somewhere.

That's one way to look at it.

> > 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.
> 
> If you don't want to change the behaviour of your OSX machine, you 
> shouldn't install portage, fink, or whatsoever, because by adding 
> software you change it's behaviour.  (It normally would say: "command 
> not found")

Absolutely right. There are some commands that should not be found, and if 
the are, some things do start to break (mainly ./configure). This is true 
regardless of the sequence you put binaries in PATH.

In such an eventuality, the user should be able to remove the problem the 
same way they installed it (emerge).

Anyway, my point is, there are ways to add new behaviour to OS X that 
don't remove old behaviour. Some people may view collision-protect as one 
way to achieve that.

BTW, if you have a bunch of bugzilla entries that complain "gentoo ebuilds 
don't like apple's perl", that is another story (and I confess that I 
haven't looked...) Things get interesting if you become obliged to have a 
prefixed perl to support the rest of portage, but you also want the user 
to have the freedom to choose the arrangement of their PATH.

-f
-- 
gentoo-osx@gentoo.org mailing list

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

[Kito]

On Aug 18, 2005, at 5:02 PM, 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.

This approach only works out of luck, it just so happens the latest  
portage perl isn't the same version as Apples currently shipping  
perl. What happens when/if the next software update decides to  
install Perl 5.8.7? collisions will occur.

Anything that installs to /System is a bad idea IMO, /Library is the  
sandbox apple encourages 3rd party developers to (ab)use.

--Kito

-- 
gentoo-osx@gentoo.org mailing list

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

[Hasan Khalil]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]


On Aug 19, 2005, at 09:45, Kito wrote:

> What happens when/if the next software update decides to install  
> Perl 5.8.7? collisions will occur.
>
> Anything that installs to /System is a bad idea IMO, /Library is  
> the sandbox apple encourages 3rd party developers to (ab)use.

You're absolutely right. I didn't change anything about where things  
were installed except for the 'bin' directory(ies). This will be  
fixed shortly.

--

Hasan Khalil
eBuild and Porting Co-Lead
Gentoo for Mac OS X


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Philipp Riegger]

On 19. Aug 2005, at 6:13 Uhr, Finn Thain wrote:

>>
>> 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.

Why not provide something like perl_select (like apples gcc_select) or 
perl-config? I use gcc_select to switch between apples gcc and gnat for 
OS X.

Philipp

-- 
gentoo-osx@gentoo.org mailing list