Error installing rdiff-backup

Scott Haneda talklists at newgeo.com
Tue Aug 18 14:32:23 PDT 2009


On Aug 17, 2009, at 9:39 PM, Ryan Schmidt wrote:

> On Aug 17, 2009, at 22:03, Scott Haneda wrote:
>
>> On Aug 17, 2009, at 7:10 PM, S. M. Ibrahim (Lavlu) wrote:
>>
>>> looks like /opt/local/bin/xattr is also used by another port xattr,
>>> and that port is already active. that's why you are getting this
>>> message. you can active manualy py25-xattr by "sudo port -f activate
>>> py25-xattr"
>>
>> It would be nice if ports could print out the versions in cases lke  
>> this. If they are equal, maybe it could just move along. A simple  
>> "yes, I want to overwrite", or a "no, I want to abort", could be a  
>> nice way of dealing with this.
>
> That doesn't sound practical to me. Are you talking about the  
> versions of the ports? If so, port xattr is version 0.1 while port  
> py25-xattr is version 0.5. Or did you mean the versions of the xattr  
> program installed by both? There isn't any standard for figuring out  
> a program's version, and besides, the conflicting file might not be  
> a program; it might be a manpage or a header file or any other type  
> of file.

I do not really know to be honest.  I just know my experiences, and I  
get those errors a lot, probably because I am fiddling around with  
perl modules more than I want to.

I think I get the basics of it, installing of app A, may install other  
pieces, like libraries, man pages, etc.  These are all registered with  
MacPorts as being active and part of that app A.  Install app B, if it  
needs to put anything in the same place as app A, you are forced to  
deal with it.

Is that correct?

> Even if they are the same version, by whatever criteria, how do you  
> know they are the same software? Ok, maybe you compute a checksum of  
> both files and discover they're identical.

would it matter?  That is broken in regards to the port developer  
then.  Ports tracks the software and location it was installed.  If  
you run md5, and they are the same, then yes, I think it would be very  
safe to move on.

> Ok, so then you allow, say, py25-xattr to install without its xattr  
> file and have it make use of the xattr file provided by the xattr  
> port. But no dependency has been declared on the xattr port. What  
> happens if now the user uninstalls the xattr port? The py25-xattr  
> port stops working.

Why can't a dependency be declared then?  If the dependency is not  
there, it will be installed, and noted as such.  If another app comes  
along, and relies on that dependency, then that app should also get a  
note that it needs it.

When you are removing an app, this "notes" database should be  
consulted, and the dependency should not be removed, until the very  
last piece of software that depends on it is being removed.

> No, I think our current strategy for this type of situation is fine.  
> Ideally there should be only one port that installs a given file.

I agree on this very much, but it never seems to be the case.

> Ports that violate this get tickets filed and assigned to both  
> maintainers so they can sort it out. Ports that can't fix such a  
> conflict will (as of MacPorts 1.8) be marked as conflicting in the  
> portfiles

Taking this down to the simplest and most no critical of examples, how  
does this work with man pages?  If installing app A installs manA(1)  
and then you install app B and it installs manA(1) as well... They  
both logically should live in the same man pages area.  This is not  
technically a conflict, but it is going to toss up an error in MacPorts.

Is the suggested method to then keep two copies of the same man page?   
This trickles down to perl modules, and all sorts of other softwares  
as well.  It is really nice that 1.8 is working to solve this, but I  
am indeed curious how it is going to be able to do so.

-- 
Scott * If you contact me off list replace talklists@ with scott@ *



More information about the macports-users mailing list