unregistered files/modules

[Ryan Schmidt]

On Oct 8, 2007, at 17:56, paul beard wrote:

> On 10/8/07, David Epstein wrote:
>
>> Paul Beard wrote:
>>
>> > On 10/8/07, David Epstein wrote:
>> >
>> >> Error: Target org.macports.activate returned: Image error: /opt/ 
>> local/
>> >> share/locale/locale.alias already exists and does not belong to a
>> >> registered port.
>> >
>> > what does "port provides /opt/local/share/locale/locale.alias"  
>> tell you? it
>> > says it's unregistered or unassociated with any installed port,  
>> so I don't
>> > think anything will be revealed. Have you installed anything  
>> manually (ie,
>> > from source w/o MacPorts) on this system?
>> > If you haven't got anything /opt/local that isn't owned by  
>> MacPorts, you can
>> > use "port -f install gnupg" to override any of the issues you're  
>> seeing.
>>
>> Thanks to everyone for very helpful comments. The whole set-up was  
>> very
>> mysterious, and has now become much clearer. The material in /opt/ 
>> local/ was
>> installed by a programmer. I have no idea how he did it, but it  
>> was a long
>> time ago, maybe before Darwinports was really up and running, let  
>> alone
>> Macports. So macports is refusing to delete these files under  
>> automation,
>> and that's obviously the right thing for port to do unless there is a
>> special flag. It is still not clear to me what will happen if I  
>> give a
>> command like "port -f install gnupg". Practically NOTHING in my large
>> /opt/local comes from MacPorts, so Paul is suggesting that I should
>> therefore not use -f. But that's exactly WHY I want to use -f.
>
> eh, not exactly ;-) but perhaps my meaning was opaque.
>
> Now that we know you have some stuff in /opt/local that you don't  
> want to deal with, here's a suggestion. Move it aside (mv /opt/ 
> local /opt/local/old), and reinstall MacPorts from scratch. My  
> guess is you'll be home free once you do that.

A-ha! Revelation! You have things in /opt/local that did not come  
from MacPorts! (Or maybe it's left over from an old MacPorts or  
DarwinPorts install which has become disconnected from your current  
MacPorts install.) Now I'm not surprised at all that you've had so  
many problems.

MacPorts likes to be in almost complete control of its prefix, likes  
to know what's in it. (It's fine to keep some config files there, but  
having other software there that MacPorts doesn't know about is not  
ok.) Paul's advice is good -- move /opt/local out of the way.  
However, you cannot move a directory into itself. So, try "mv /opt/ 
local /opt/local-old"

Alternately, you could build MacPorts from source and use "./ 
configure --prefix=/somewhere/else" to tell MacPorts not to use /opt/ 
local but a different prefix of your choosing. But it might be  
clearer if you just move your existing /opt/local away and let  
MacPorts use its defaults.


>> A number of
>> my programs in /opt/local just don't work on my new Intel Mac, so  
>> I have to
>> upgrade. What are the dangers of using -f? Would it help me, in  
>> view of the
>> fact that the files I want to delete do not come from MacPorts? Or  
>> would
>> MacPorts still refuse to delete? I don't like the idea of using a  
>> force
>> command without knowing fairly well what damage it might do.
>
> All it will do is overwrite old files and move aside the old  
> versions of the files it replaces.

Using -f would work... ish... in that it would rename the existing  
files and then install the new files. But it would be clearer if you  
start with a clean slate so that you know everything in /opt/local  
came from MacPorts. Otherwise, as you're installing ports, some ports  
might start linking against your old libraries in /opt/local and  
things might continue to break in exciting ways.


> You can see why I'm not happy with the output from "man port" which  
> explains
> -f as "force mode (ignore state file)". I don't know what "state  
> file" means, and
> man doesn't say whether port's actions are confined to files  
> installed by
> MacPorts. There must be documentation that says what "state file"
> means---could a kind person direct me to it? Thanks very much.

Indeed. That's one of the first comments I made on this list years  
ago. I'm not sure the situation has improved any since then, though  
the new MacPorts guide may explain it better (I haven't had time to  
read the new guide yet).


On Jul 30, 2005, at 09:53, Ryan Schmidt wrote:

> The question was asked before and the answer was to RTFM (referring  
> to the port manpage) and to use "force." But the only thing "man  
> port" says about the "force" option is that it exists, not what it  
> does or when or when not to use it. ([The manpage] says it will  
> "ignore [the] state file" but a casual DarwinPorts user like myself  
> has no idea what that means.)
>
> The DarwinPorts manual also only has a very little to say about  
> "force", and especially the last sentence makes it sound like I  
> should not use it:
>
> "While upgrading you can run into cases when you have to use force  
> (-f). This is especially true if you are upgrading a port that  
> wants to install a file that another port allready (sic) has  
> installed, or if you use the -u option to upgrade (and uninstall) a  
> port that could be installed as a dependency. Allways (sic)  
> remember to use the -f option with caution."
[snip]
> If, as you seem to suggest, using "force" is such an essential  
> component to successfully using DarwinPorts, I would like to  
> suggest that the above section in the manual be extended to explain  
> this use, and to explain the other circumstances in which it would  
> be inadvisable to use "force." As it is, a statement to use it  
> "with caution" is quite flummoxing, as it does not provide  
> sufficient background for the reader to really understand the  
> implications.

The old OpenDarwin archive is gone, but that thread is still here:

http://archive.netbsd.se/?ml=darwinports&a=2005-07&t=1110450