Error installing rdiff-backup

[Ryan Schmidt]

On Aug 18, 2009, at 16:32, Scott Haneda wrote:

> 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.

There have been a set of perl modules which are included with the  
perl port, which are also available as separate module ports. These  
separate module ports conflict with the modules installed by the perl  
port, and so the activation must be forced. These separate module  
ports print out an additional message advising the user to do this.  
This situation is not ideal, because ideally a user should never have  
to force an activation in normal use, but it is the situation we have  
right now for those ports until someone comes up with a better solution.


> 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?

Yes, depending on who you mean by "you". I state that the port  
maintainers are the "you" that need to deal with it. Until they do,  
the user may have one port or the other active but not both. Or both,  
by forcing the activation, if the user wishes to accept  
responsibility for what might happen as a result.


>> 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.

Yes, and the port developers need to be informed about the problem  
and then fix it.

> 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.

A port should install the same software on any computer, regardless  
of what other software a user may already have on his system. It  
should not magically start depending on some other port just because  
it happened to already be installed. That is, if a port author wanted  
to add logic to the portfile to do that, that could be ok depending  
on the circumstance, but MacPorts base should not decide to do so on  
its own.


>> 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.

I'm sure at least 99% of our ports do not conflict.


>> 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.

It is a conflict. Two ports should not both attempt to install the  
same file (manpage or otherwise). A bug should be filed. The  
maintainers of both ports should agree who should own the file and  
fix the other port to not install the file. Maybe one or both files  
need to be renamed in order to avoid the conflict.


> 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.

I'm not aware of changes in 1.8 dealing with this, but I'm also not  
totally familiar with all changes that have gone into trunk since the  
1.7.1 release.