render port is being replaced with xorg-renderproto port

Ryan Schmidt ryandesign at macports.org
Mon Nov 10 02:59:16 PST 2008


On Nov 10, 2008, at 04:28, Emmanuel Hainry wrote:

> Citando Ryan Schmidt :
>
>> This message is relevant to anyone using ports that until now  
>> depended on
>> the render port:
>>
>> * cairo / cairo-devel
>> * gthumb
>> * gtk2
>> * libgdiplus
>> * rxvt-unicode
>> * wine / wine-devel
>> * xrender
>>
>> The render port has been replaced with the xorg-renderproto port.  
>> They
>> are the same software; the latter is just a newer version. So we are
>> removing the render port.
>
> Don't we have a better way of dealing with port name changes (or  
> similar
> issues)?

I wish we did. It would be nice to be able to specify in a port that  
it has been superseded by another. But we don't have that.

> This change creates two conflicting ports,

That is the situation we have already had ever since the xorg- 
renderproto port was added in June 2007. The person who added it  
probably didn't realize we already had that software in the render  
port. But it is part of xorg and its proper name is now renderproto,  
so the newer port's name is the better one.

> if one of the
> dependents is not updated, it will mean some ports (potentially  
> half of
> the ports related to X) won't be installable.


That is why today I have changed all the ports that depended on  
render to depend on xorg-renderproto instead.

> Isn't it possible to update render to a pseudo newer version that  
> has no
> file

Yes, I just did that. Unfortunately I had not completed all my  
modifications by the time the portindex was regenerated, so I wanted  
to notify users of the issue.

> but depends on xorg-renderproto? Or else to have some kind of
> "superseding" mechanism?

Making render depend on xorg-renderproto will not work: the  
dependency xorg-renderproto would be built first before render would  
be updated to the no-files version. You would be guaranteed to get  
exactly the conflict message we're trying to avoid.

Making xorg-renderproto depend on render might work. I could change  
the render port again to not issue the message I added, advising  
users to uninstall it, but instead let it sit around empty for awhile  
until everyone has upgraded. Then later I can increase the revision  
and re-add that message. I don't know if this is better than what I  
did; it's all a bit messy. If someone feels strongly about this they  
can change things. For now, I'm going to bed. :)




More information about the macports-users mailing list