On Fri, August 19, 2005 06:13, Finn Thain wrote:
> Nice work!
>> ... '/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
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
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
> 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
What if some nifty app depends on Apple's perl? Sounds not like a good
> 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.
email@example.com mailing list