Mailing List Archive

collision-protect
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, tons of stuff in bugzilla that users are submitting could be
keyworded, but due to a 'policy' that I'm not completely clear on, can
not be because the ebuilds would overwrite Apple provided files. My
first suggestion was just use the ppc-darwin keyword for said ebuilds,
however usata brought up some valid points in bug #65763 that made this
seem less than ideal, and even though I was the one who recommended it,
I've since changed my mind(flip-flopper!).

At this point, I believe I'm the only dev that has a Darwin environment
to test in, and I'm quite sure none of our users are testing this stuff
in darwin. That being said, it wouldn't seem right for me to declare a
package as stable when I'm the only one in the world who has actually
used and tested said package in the Darwin userland. This also assumes
I myself could keep up with all these and actually have the
time/knowledge/motivation to use and test every package that our users
claim to be working.

I do believe there are users that actually WILL want to replace things
that apple shipped(i.e. a cvs client that isn't linked against the
kerberos framework...yuck), but on the other hand, many people will
want to use portage while leaving the system files untouched.

IIRC pvdabeel stated this should just be decided on a per package
basis, but IMHO a more general solution could speed up dev time.

I don't have a solution, but right now I'm leaning towards a USE flag
or possibly a FEATURE that would give the users a little more
flexibility in choosing how they want portage to live on their system.

Thoughts, opinions, criticisms, flames, ideas ?

Kito
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)

iD8DBQFBat3XJ0rMK/3OwgsRAuroAKCp+G8yQlJ/6byvGyjLvZvgT3twqgCfQOXX
cQV9ewVlCkNupSCfpDLijF8=
=KrSl
-----END PGP SIGNATURE-----


--
gentoo-osx@gentoo.org mailing list
Re: collision-protect [ In reply to ]
On Oct 11, 2004, at 12:24 PM, Kito wrote:
>
> At this point, I believe I'm the only dev that has a Darwin
> environment to test in, and I'm quite sure none of our users are
> testing this stuff in darwin. That being said, it wouldn't seem right
> for me to declare a package as stable when I'm the only one in the
> world who has actually used and tested said package in the Darwin
> userland. This also assumes I myself could keep up with all these and
> actually have the time/knowledge/motivation to use and test every
> package that our users claim to be working.

I'd be happy to test, but I want to see a chroot'd install.

> I don't have a solution, but right now I'm leaning towards a USE flag
> or possibly a FEATURE that would give the users a little more
> flexibility in choosing how they want portage to live on their system.
>
> Thoughts, opinions, criticisms, flames, ideas ?

Chroot the install! It solves a huge number of issues…you don't risk
overwriting anything, to start with, and nothing gets clobbered in an
OS upgrade or archive. Users can edit $PATH to have Gentoo binaries be
used over OS ones, or someone could make a shell script to make aliases
to have Gentoo commands run over OS ones.

Also…in a lot of OS X troubleshooting one step that may be recommended
(by Apple and others) is an Archive/Install. Blam! You've zapped your
Gentoo stuff, unless you know how to copy it back into your active /usr
and /bin directories.

In short, chroot'd Gentoo will keep users happy, be simpler, win us the
war, and solve world hunger.

Cap'n Hector

--
gentoo-osx@gentoo.org mailing list
Re: collision-protect [ In reply to ]
Kito wrote:

> I do believe there are users that actually WILL want to replace things
> that apple shipped(i.e. a cvs client that isn't linked against the
> kerberos framework...yuck), but on the other hand, many people will
> want to use portage while leaving the system files untouched.


Correct. One point that sets Gentoo Mac OS apart from the two other
major package management systems on Darwin / OS X (Fink and DarwinPorts)
is that it doesn't use a chrooted environment, and for me, that's a
*plus* point. I do not want to end up having all sorts of binaries two
or three times in my system, or having to figure out "alright, is this
GNU ls? and if so, which package manager is this version from?".

I would opt for a USE flag, "macos-override" or something. However,
please keep in mind that Apple's Installer likes being broken and
randomly overriding things. (For example, try moving around bundles in
/Applications, such as moving them to a newly-created
/Applications/Internet or /Applications/Tools, then running Software
Update. Don't be surprised if this breaks things; it's happened to me
before.) Also, it will be a good idea to do backups; e.g. rather than
overriding /usr/bin/cvs with gentoo's, move it to
/usr/bin/apple-provided/cvs.

Just my two cents and paragraphs.

--

Soeren 'Chucker' Kuklau

--
gentoo-osx@gentoo.org mailing list
Re: collision-protect [ In reply to ]
Kito wrote:

> I do believe there are users that actually WILL want to replace things
> that apple shipped(i.e. a cvs client that isn't linked against the
> kerberos framework...yuck), but on the other hand, many people will
> want to use portage while leaving the system files untouched.
>
> IIRC pvdabeel stated this should just be decided on a per package
> basis, but IMHO a more general solution could speed up dev time.
>
> I don't have a solution, but right now I'm leaning towards a USE flag
> or possibly a FEATURE that would give the users a little more
> flexibility in choosing how they want portage to live on their system.

The easiest and probably obvious solution is to keyword those packages
ppc-darwin, and then let users that want to overwrite Apple files accept
keywords ppc-macos and ppc-darwin and turn off collision protect. I
don't see the need for a USE flag or FEATURE. It doesn't change the
functionality of an installed program (as USE flags do), and FEATURE
can't be used to keyword packages AFAIK.

--Lina

--
gentoo-osx@gentoo.org mailing list
Re: collision-protect [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Oct 11, 2004, at 2:35 PM, Cap'n Hector wrote:

>
> On Oct 11, 2004, at 12:24 PM, Kito wrote:
>>
>> At this point, I believe I'm the only dev that has a Darwin
>> environment to test in, and I'm quite sure none of our users are
>> testing this stuff in darwin. That being said, it wouldn't seem right
>> for me to declare a package as stable when I'm the only one in the
>> world who has actually used and tested said package in the Darwin
>> userland. This also assumes I myself could keep up with all these and
>> actually have the time/knowledge/motivation to use and test every
>> package that our users claim to be working.
>
> I'd be happy to test, but I want to see a chroot'd install.
>
>> I don't have a solution, but right now I'm leaning towards a USE flag
>> or possibly a FEATURE that would give the users a little more
>> flexibility in choosing how they want portage to live on their
>> system.
>>
>> Thoughts, opinions, criticisms, flames, ideas ?
>
> Chroot the install! It solves a huge number of issues…you don't risk
> overwriting anything, to start with, and nothing gets clobbered in an
> OS upgrade or archive. Users can edit $PATH to have Gentoo binaries be
> used over OS ones, or someone could make a shell script to make
> aliases to have Gentoo commands run over OS ones.

Well, not all of us want /gentoo or whatever... so i guess the options
are wait for PATHSPEC, implement some chroot FEATURE and write some env
scripts ala fink, or continue making the 'g'util ebuilds such as (g)sed
etc.

>
> Also…in a lot of OS X troubleshooting one step that may be recommended
> (by Apple and others) is an Archive/Install. Blam! You've zapped your
> Gentoo stuff, unless you know how to copy it back into your active
> /usr and /bin directories.
>
> In short, chroot'd Gentoo will keep users happy, be simpler, win us
> the war, and solve world hunger.
>
> Cap'n Hector
>
> --
> gentoo-osx@gentoo.org mailing list
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)

iD8DBQFBauj6J0rMK/3OwgsRAnjkAJ9DwRje/bReSBuTlNQX8n5dNHDhPQCeI5iS
ZAi8VKd7Wqpyzmd3ckT6c2A=
=b4w8
-----END PGP SIGNATURE-----


--
gentoo-osx@gentoo.org mailing list
Re: collision-protect [ In reply to ]
On Oct 11, 2004, at 1:04 PM, Soeren Nils Kuklau wrote:

> I would opt for a USE flag, "macos-override" or something. However,
> please keep in mind that Apple's Installer likes being broken and
> randomly overriding things. (For example, try moving around bundles in
> /Applications, such as moving them to a newly-created
> /Applications/Internet or /Applications/Tools, then running Software
> Update. Don't be surprised if this breaks things; it's happened to me
> before.) Also, it will be a good idea to do backups; e.g. rather than
> overriding /usr/bin/cvs with gentoo's, move it to
> /usr/bin/apple-provided/cvs.

I'll re-state myself…Given how Apple troubleshoots the OS, a
non-chroot'd install is the wrong way to go…many issues end up having
an archive/install done to fix them, and you loose all the Gentoo
files.

As it is, I'm using DarwinPorts and Fink since they both survive my
routine system purges (rm -fr /System /Library /usr /bin /sbin /private
).

A possible compromise: Have a chroot'd install (preserves in an
archive, easy to back up, etc), and have a script that moves Apple
binaries to $binname.apple and does an ln -s /gentoo/$bindir
/apple/bin/path

Cap'n Hector
--
gentoo-osx@gentoo.org mailing list
Re: collision-protect [ In reply to ]
Cap'n Hector wrote:
> I'd be happy to test, but I want to see a chroot'd install.

Ditto (for ppc-darwin).

> In short, chroot'd Gentoo will keep users happy, be simpler, win us the
> war, and solve world hunger.

I think you forgot to say that it makes everyone beautuful like me too.
And it'll give Revlon to all the starving little girls in Africa.

--

Hasan Khalil <gongloo@gentoo.org>
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x707B8F18
Re: collision-protect [ In reply to ]
On Oct 11, 2004, at 8:24 pm, Kito wrote:
>
> .... due to a 'policy' that I'm not completely clear on, can not be
> because the ebuilds would overwrite Apple provided files.

I hope this is an enduring policy, too.

I really like Gentoo and am quite prepared to run `etc-update` & fix
things after I run `emerge sync` on my Linux server every couple of
months. But I use OS X for my desktop because it just works, it never
breaks & because I don't have to think about it.

If you allow Gentoo to overwrite Apple-installed files then Apple WILL
over-write Gentoo-installed files during some future update or upgrade,
and one of you WILL (at some point) break things on installed systems.

Stroller.


--
gentoo-osx@gentoo.org mailing list
Re: collision-protect [ In reply to ]
Stroller wrote:
>
> On Oct 11, 2004, at 8:24 pm, Kito wrote:
>
>>
>> .... due to a 'policy' that I'm not completely clear on, can not be
>> because the ebuilds would overwrite Apple provided files.
>
>
> I hope this is an enduring policy, too.
>
> I really like Gentoo and am quite prepared to run `etc-update` & fix
> things after I run `emerge sync` on my Linux server every couple of
> months. But I use OS X for my desktop because it just works, it never
> breaks & because I don't have to think about it.
>
> If you allow Gentoo to overwrite Apple-installed files then Apple WILL
> over-write Gentoo-installed files during some future update or upgrade,
> and one of you WILL (at some point) break things on installed systems.

I couldn't agree more. I'm in more-or-less the same boat (although I use
Mac OS not only because it Just Works(tm) but also because I need to run
things, such as Photoshop (no, Gimp won't cut it, and for those of you
who thinks it can, try it in the real design world -- I have),
Illustrator, Flash, etc.

The point is, though, that I use Mac OS and I want to keep Mac OS the
way it is. I want to add things to it, not change what's already there
(theoretically).

IMHO, a different keyword is the easiest (no additional code required)
to use for this.

--

Hasan Khalil <gongloo@gentoo.org>
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x707B8F18