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.)
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
