Collision Protection: which files are ok??

[BennyP]

I can't use the FEATURE="-collision-protect" option when emerging.
Because it's supposed to read

Code: Select all

FEATURES="-collision-protect"

I'm updating portage now, and the coreutils ebuild want to overwrite a whole whack of files. is it safe to let it do that?? here's the list:

Code: Select all

existing file /bin/[ is not owned by this package
existing file /bin/cat is not owned by this package
existing file /bin/chmod is not owned by this package
existing file /bin/cp is not owned by this package
existing file /bin/date is not owned by this package
existing file /bin/dd is not owned by this package
existing file /bin/df is not owned by this package
existing file /bin/echo is not owned by this package
existing file /bin/expr is not owned by this package
existing file /bin/ln is not owned by this package
existing file /bin/ls is not owned by this package
existing file /bin/mkdir is not owned by this package
existing file /bin/mv is not owned by this package
existing file /bin/pwd is not owned by this package
existing file /bin/rm is not owned by this package
existing file /bin/rmdir is not owned by this package
existing file /bin/sleep is not owned by this package
existing file /bin/stty is not owned by this package
existing file /bin/sync is not owned by this package
existing file /usr/bin/basename is not owned by this package
existing file /usr/bin/chgrp is not owned by this package
existing file /usr/bin/cksum is not owned by this package
existing file /usr/bin/comm is not owned by this package
existing file /usr/bin/cut is not owned by this package
existing file /usr/bin/du is not owned by this package
existing file /usr/bin/env is not owned by this package
existing file /usr/bin/expand is not owned by this package
existing file /usr/bin/false is not owned by this package
existing file /usr/bin/fmt is not owned by this package
existing file /usr/bin/fold is not owned by this package
existing file /usr/bin/head is not owned by this package
existing file /usr/bin/id is not owned by this package
existing file /usr/bin/install is not owned by this package
existing file /usr/bin/join is not owned by this package
existing file /usr/bin/logname is not owned by this package
existing file /usr/bin/mkfifo is not owned by this package
existing file /usr/bin/nice is not owned by this package
existing file /usr/bin/nohup is not owned by this package
existing file /usr/bin/od is not owned by this package
existing file /usr/bin/paste is not owned by this package
existing file /usr/bin/pr is not owned by this package
existing file /usr/bin/printenv is not owned by this package
existing file /usr/bin/printf is not owned by this package
existing file /usr/bin/sort is not owned by this package
existing file /usr/bin/split is not owned by this package
existing file /usr/bin/sum is not owned by this package
existing file /usr/bin/tail is not owned by this package
existing file /usr/bin/tee is not owned by this package
existing file /usr/bin/touch is not owned by this package
existing file /usr/bin/tr is not owned by this package
existing file /usr/bin/tsort is not owned by this package
existing file /usr/bin/tty is not owned by this package
existing file /usr/bin/uname is not owned by this package
existing file /usr/bin/unexpand is not owned by this package
existing file /usr/bin/uniq is not owned by this package
existing file /usr/bin/users is not owned by this package
existing file /usr/bin/wc is not owned by this package
existing file /usr/bin/who is not owned by this package
existing file /usr/bin/yes is not owned by this package

[blubbfisch]

I can't use the FEATURE="-collision-protect" option when emerging.

Easy: The variable is called FEATURES, not FEATURE

some examples:

Code: Select all

Last login: Mon Aug 23 21:18:29 on ttyp1
Welcome to Darwin!
-bash: /sw/bin/init.sh: No such file or directory (how can i get rid of this??  I deleted every fink file and fink is not in PATH)
[/quote]
edit your ~/.profile or ~/.bashrc or your ~/.chsrc (depending on your shell) and remove the line that sources /sw/bin/init.sh

Have fun*

Niklas

[BennyP]

Thank you!

[JoseJX]

You shouldn't overwrite the coreutils, there are some differences between the GNU utils that the coreutils build installs and the BSD utils that come with OSX. You will probably need to replace uname if you've already forced coreutils to install. A new version of coreutils has been written that addresses the problems with the existing ebuild. Remember that collision-protect is to protect you from messing up your existing OSX install. If you're comfortable with potentially messing things up really badly, then turn it off, but if you're not sure, it's best to leave it on and report broken packages.

[onkelfusspilz]

Hi JoseJX,

you say it's not a good idea of disabling collision-protection and I think you're right since I wrecked up my system unbootable overwriting coreutils.
But I don't see a way living with collision-protection enabled since I was not able to emerge any package cleanly (I tried vim, nano, mc, nmap and some more) because of file-collision.

The point is that you say it is the best way to report this packages as broken, but is this really the golden way if we look some month's in the future?
Please think about this situation: A Apple security update replaces several system-files, and maybe overwrites some files installed with portage before the security update. I think this may couse some of these problems:
1.) The package installed by portage does'nt work anymore (another version overwrites our lib or s.l.t.).
2.) A update with portage will kill the updated version from apple, so the system-programs may run into problems
3.) A re-emerge is not possible anymore because the "fix" who was added to the package since it was marked as "broken" by our report doesn't handle the newer file-versions.

Sorry don't get me wrong but I really don't know how to handle this and I don't believe that it is possible to share the root-fs with two distributions who don't know anything about each other. In my example it is only a security update of some files but what if we change to MacOSX 10.4 or 10.5 or whatever the future brings in?

So do I stuck in the middle and get it wrong or is the situation so unclear as I see it?

I think portage is intended for MacOSX package handling because of it's ebuild architecture, but I don't see a chance in sharing the root-fs. How do you see the situation?

Thank you