View previous topic :: View next topic |
Author |
Message |
BennyP Guru
Joined: 09 May 2003 Posts: 503 Location: Jerusalem, Israel
|
Posted: Tue Aug 24, 2004 2:05 am Post subject: Collision Protection: which files are ok?? |
|
|
I can't use the FEATURE="-collision-protect" option when emerging.
Because it's supposed to read Code: | 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: | 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 |
_________________ Could it be?
Last edited by BennyP on Tue Aug 24, 2004 6:34 am; edited 2 times in total |
|
Back to top |
|
|
blubbfisch n00b
Joined: 19 Oct 2003 Posts: 55 Location: World->Pacific->New Zealand->Hamilton
|
Posted: Tue Aug 24, 2004 4:40 am Post subject: Re: Can't disable collision-protect |
|
|
BennyP wrote: | I can't use the FEATURE="-collision-protect" option when emerging.
|
Easy: The variable is called FEATURES, not FEATURE
Quote: |
some examples:[code]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)
|
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 |
|
Back to top |
|
|
BennyP Guru
Joined: 09 May 2003 Posts: 503 Location: Jerusalem, Israel
|
Posted: Tue Aug 24, 2004 5:58 am Post subject: |
|
|
Thank you! _________________ Could it be? |
|
Back to top |
|
|
JoseJX Retired Dev
Joined: 28 Apr 2002 Posts: 2774
|
Posted: Tue Sep 21, 2004 2:39 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
onkelfusspilz Tux's lil' helper
Joined: 26 Aug 2002 Posts: 130 Location: Germany
|
Posted: Sat Oct 30, 2004 3:45 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|