pureftpd: update, rename to pure-ftpd

[scott@…]

Attached is a new portfile. You will notice there is aleady a port of "pureftpd". I am not sure how to deal with the name change. This port is correctly named pure-ftpd.

Significant amounts of the source have changed compared to the current port available to users. Multiple files were installed referencing non prefix locations.

I do not see any way that a port upgrade pureftpd would not make a rather large mess.

Proper procedure would be, backup, port uninstall pureftpd, port install pure-ftpd

Mention was made to there being a provision for a port renaming scheme, but since I am not versed in that, and can not find any docs, I would like to get this port into the system. I think it is more important to get this port in place, as it solves many issues the old port did not. This port also has an active maintainer that uses the port every day :)

Now, to go remove the old port, and put this one in place... fun.

[ryandesign (Ryan Carsten Schmidt)]

We can leave the pureftpd port around as a stub to help people upgrade to pure-ftpd (using the replaced_by keyword).

I'm looking through the new portfile now.

[scott@…]

Replying to ryandesign@…:

We can leave the pureftpd port around as a stub to help people upgrade to pure-ftpd (using the replaced_by keyword).

I'm looking through the new portfile now.

If you know how to do that, I did not. I am guessing, you remove the pureftpd Portfile, and it would more or less do nothing, other than tell you to go install something else? I am fine with that. I believe it will be very important that any activated pureftpd ports be backed up, deactivated and then pure-ftpd put in place.

It would probably be worse to not change the name, as an upgrade would then be easily possible, leaving a good deal of mess behind. Much like I believe what will make moving Apache2 to a more appropriate location is going to be challenging, this is similar. The name change in this case, makes it easier.

[ryandesign (Ryan Carsten Schmidt)]

My plan is to use the replaced_by keyword, which will mean that any user who has pureftpd installed will be informed via port outdated that a new version is available, and when they port upgrade pureftpd, pureftpd will be deactivated and pure-ftpd will be installed. It will be practically the same, from the user's perspective, as if we had just updated the existing pureftpd port. What mess do you believe this will leave behind?

[ryandesign (Ryan Carsten Schmidt)]

I committed the update in r61772.

The mysql5 and tls variants compile fine but the postgresql variant doesn't because you haven't told it where the postgresql files are installed. I also wanted to suggest you offer postgresql82, postgresql83, and postgresql84 variants to let the user choose.

[ryandesign (Ryan Carsten Schmidt)]

This​ fixes postgresql. Any objections to committing it?

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

I committed the update in r61772.

I forgot to mention that I made the following changes to your submission:

• Reindented the file at 4 spaces per tab instead of 5
• Fixed your launchd plist to not hardcode /opt/local
• Fixed your post-destroot to create directories inside ${destroot}${prefix} and use destroot.keepdirs instead of creating directories directly in ${prefix}
• Fixed the openssl dependency in the tls variant

[scott@…]

Replying to ryandesign@…:

I committed the update in r61772.

The mysql5 and tls variants compile fine but the postgresql variant doesn't because you haven't told it where the postgresql files are installed. I also wanted to suggest you offer postgresql82, postgresql83, and postgresql84 variants to let the user choose.

Thanks for the postgres diff, I have no idea what happened, I solved that just before I posted the portfile. Messy file management on my end I suspect. Thank you.

[ryandesign (Ryan Carsten Schmidt)]

No problem, postgresql variant diff committed in r61831. I think that does it for this ticket!

[scott@…]

Replying to ryandesign@…:

Replying to ryandesign@…:

I committed the update in r61772.

I forgot to mention that I made the following changes to your submission:

• Reindented the file at 4 spaces per tab instead of 5
• Fixed your launchd plist to not hardcode /opt/local
• Fixed your post-destroot to create directories inside ${destroot}${prefix} and use destroot.keepdirs instead of creating directories directly in ${prefix}
• Fixed the openssl dependency in the tls variant

Id 4 spaces per tabs a "best practices" issue in MacPorts? I really do not care one way or the other.

@PREFIX@ ah ha, so that is how that is done, thank you!

Thanks on the port-destroot create dirs changes, I was not aware of how to do that, so I did the best I knew at the time.

And thanks again on the openssl "depends_lib-append port:openssl " changes. I guess I had that in place, so it never bothered me.

Sounds like a good idea for me to set up a second prefix, one I use for working in, and one I use for developing in, that was I would have caught all of these. Any new port, I can sudo -df port uninstall all on the secondary prefix, and then try to install just my one port, with all variants. Is that the suggested method to come out with more rock solid port submissions?

[ryandesign (Ryan Carsten Schmidt)]

Replying to scott@…:

Id 4 spaces per tabs a "best practices" issue in MacPorts? I really do not care one way or the other.

Yeah, it's how most other ports do it, and it's ​in the guide.

@PREFIX@ ah ha, so that is how that is done, thank you!

Yes, you just put some string into the file that wouldn't otherwise occur, then reinplace it. I use "@PREFIX@", I've seen others use "@@PREFIX@@" or "__PREFIX" or "MACPORTS_PREFIX" or similar. Doesn't matter what it is, as long as it's not already in the file.

Thanks on the port-destroot create dirs changes, I was not aware of how to do that, so I did the best I knew at the time.

This way, the directories essentially also get registered to the port, so they disappear when the port is uninstalled -- if they're empty, that is.

And thanks again on the openssl "depends_lib-append port:openssl " changes. I guess I had that in place, so it never bothered me.

The port had that line in it before your changes, but yeah, there were several reasons it needed to be changed.

Sounds like a good idea for me to set up a second prefix, one I use for working in, and one I use for developing in, that was I would have caught all of these. Any new port, I can sudo -df port uninstall all on the secondary prefix, and then try to install just my one port, with all variants. Is that the suggested method to come out with more rock solid port submissions?

That sounds time-consuming and complicated. :) I don't go to that much effort myself. Ports don't have to be perfect either. I just fixed the things I noticed. If I missed them, someone else might've seen them later, and filed a bug report, and it could be fixed then.