Test development of pre-release software

[Ryan Schmidt]

On Oct 21, 2009, at 15:30, Scott Haneda wrote:

> I have been working with the pureftpd developer to get some source  
> changes made.  I can build the software by checking out from git.
>
> I would like to start the portfile redo, can someone tell me how to  
> do a local dev of this with a source set that is not at an official  
> url?  Do I just point the url to file:///some/place ?

If you have a tarball, just put it where MacPorts expects it (/opt/ 
local/var/macports/distfiles/pureftpd).

If you want to fetch from git, you can do that with "fetch.type git".


> There is capacity to do TLS, which means a SSL cert.  In the  
> portfile there is a variant of tls, which just adds the with-tls  
> configure option. It is then up to me to copy the included certs in  
> place.  Is there any reason I should not copy those in place for the  
> user if that variant is selected?  They do not hurt anything to  
> exist, they still need to be enabled with the launchd startup  
> plist.  Ie: they are benign, even if installed.

Sounds reasonable.


> In the next release, inetd will be deprecated.  As I am finding, all  
> the plist items for launchd that are on the interwebs are using a  
> seuperserver.  This means that a port upgrade in the next release is  
> going to break everyone's pureftpd, since the entire functionality  
> is removed.
>
> What is the best way to deal with this?  My intention now is to  
> remove inetd fro the compile options in this current release. Would  
> a ui message pointing to a new template plist file I will be making  
> suffice in this case?
>
> I am a little concerned, as there is clear case that there is going  
> to be breakage on port upgrade, since source code functionality is  
> planned for deprecation.
>
> I do not think making a newly named port is the correct way.  Are  
> there any provisions in Mac Ports that I am missing for gracefully  
> dealing with this case?

We don't have any built-in functionality for ports doing different  
things on upgrade vs. initial install. I'm never quite sure how to  
handle this either. In php5, for example, I simply don't handle it,  
requiring the user to notice e.g. that some features that used to be  
built into php5 are now in separate ports.

You could perhaps print a ui_msg all the time, wording it in a way  
that makes sense to both new and existing users, or do something  
clever, like read the user's config file (plist?) and output a message  
only if it exists and calls for the deprecated functionality. I do  
this in the php5extension portgroup so that if the user's php.ini  
contains a problematic line, a message is printed telling the user to  
remove it. (If the line was never there or has already been removed,  
no message is printed.)