port upgrade outdated

[Ryan Schmidt]

On May 2, 2009, at 11:51, Thomas De Contes wrote:

> Le 26 avr. 09 à 17:59, Rainer Müller a écrit :
>
>> Thomas De Contes wrote:
>>
>>> --->  Activating xorg-renderproto @0.9.3_0
>>> Error: Target org.macports.activate returned: Image error: /Users/
>>> thomas/Documents/prgm/bin/autoinstall/macports/include/X11/ 
>>> extensions/
>>> render.h is being used by the active render port.  Please deactivate
>>> this port first, or use 'port -f activate xorg-renderproto' to force
>>> the activation.
>>> Error: The following dependencies failed to build: xorg-renderproto
>>> Error: Unable to upgrade port: 1
>>
>> render has been replaced by xorg-rendrproto. render has been a dummy
>> port for a long time and was removed afterwards. Probably you did not
>> upgrade in a long time and thus running into this problem.
>
> it is probable
>
> well, if i did upgrade when render was a dummy port, there was a  
> mechanism to swith from render to xorg-rendrproto quietly ? :-)

While the render port was a dummy port, it installed no files.  
Therefore, it could not conflict with the files in the xorg- 
renderproto replacement port. And its revision had been incremented.  
And render was declared as a dependency of xorg-renderproto. Thus,  
for any port that depended on the new xorg-renderproto, you would  
first be made to upgrade render to the version that installed no  
files, and then xorg-renderproto would install those files.


> since i have often problems when i try to upgrade, i do it only  
> when i need it ... maybe i'm wrong ;-)

I would like for any user, regardless of how old their MacPorts  
installation is, to be able to use "sudo port selfupdate" and "sudo  
port upgrade outdated" and have it work. Unfortunately, over time,  
things do break. In this case, dummy ports get removed. So sometimes  
you will run into issues.

Upgrading more often is of course not guaranteed to cause fewer  
issues. If you had upgraded more recently, while the render dummy  
port still existed, you would not have run into this specific issue,  
but you might have encountered any number of other issues.


>>   sudo port -f uninstall render
>>   sudo port -v install xorg-renderproto
>
> thank you :-)
>
> i don't like -f very much,

Its use should be avoided and reserved for special cases. This is one  
such special case.


> is there an option to recursively uninstall the ports that depend  
> on it,
> in the same way that "port install" recursively installs the ports  
> witch it depends on ?
> (is it english ?)

There is the port_cutleaves script (for which there is a port of the  
same name) to help you identify ports that are installed but no  
longer needed. However, anything that used to depend on render will  
now depend on xorg-renderproto.


>>> --->  Fetching scrollkeeper
>>> Error: Target org.macports.fetch returned:
>>>
>>> scrollkeeper is superseded by port rarian; use that port instead
>>>
>>> Error: Unable to upgrade port: 1
>>>
>>>
>>> for this one, it would be nice if MacPorts was able to uninstall it
>>> properly itself
>>
>> No, we are currently not able to decide if it is safe to uninstall  
>> this
>> port. Be assured if there would have been a better way to replace a
>> port, it would have been used :-)
>
> ok
> can't you use the same mechanism to swith from scrollkeeper to  
> rarian, that you used for render -> xorg-rendrproto ?

It looks like scrollkeeper was changed to a no-op port which now  
simply outputs the message "scrollkeeper is superseded by port  
rarian; use that port instead".

I would have liked for the render port to have been kept around for  
much longer, at least 6 months, to facilitate upgrades for infrequent  
upgraders, but the port was removed a lot sooner, and I didn't bother  
to go back and reinstate it.


Rather than trying to find solutions for individual ports like this,  
we should come up with a global solution for renaming / superseding /  
deprecating ports and implement it in base.