sslh - upgrade to 1.13b

[fracai]

Version bump for sslh to the latest release.

I wasn't sure how to handle the "sub version", so I created that variable and modified distname and worksrcdir. The distfile is named 1.13b, but extracts to 1.13

Also, the libconfig port was broken for me (#35488), but libconfig-hr built fine, so I selected that port to satisfy the libconfig dep, which had been disabled in previous versions.

[fracai]

sslh Portfile diff

[fracai]

Also, I expanded the destroot section to include an example config, the README files, and both sslh binaries (-fork and -select), with a symlink from sslh-fork to sslh. That could be a candidate for a variant, though I don't think it's necessary.

[ryandesign (Ryan Carsten Schmidt)]

libconfig has been fixed. Does that alter whether you'd like libconfig or libconfig-hr to be the dependency?

"lib:"-style dependencies should almost never be used because they would allow the dependency to be satisfied by libraries not installed by MacPorts. Instead, you want a "port:"-style dependency, if only one port can satisfy it, or a "path:"-style dependency, if several ports providing the same file could satisfy it.

I'm confused: are you the maintainer, filing this ticket under a different email address from the one listed in the portfile?

[macports@…]

Arno is not me (the original maintainer). I was going to sit this release (1.13b) out because I didn't want to bother dealing with the naming discrepancy, but if Arno wants to take care of it then great. He seems to be more knowledgeable about the ports system as well, so even better.

[fracai]

I'm not the maintainer. I just noticed that it was out of date and wasn't linking to libconfig.

The README actually specifies the -hr implementation of libconfig. I don't know that the newly fixed version would be incompatible, but it's probably best to just change it to a "port:libconfig-hr" dep.

Would you like an updated diff?

And thanks for the clarification on "lib:". I didn't realize it would allow libs outside of MacPorts.

[fracai]

I wouldn't say I'm all that extra knowledgeable, and the naming did throw me at first. I don't know why they didn't release this as 1.13.2 instead of tacking on that silly 'b'.

[ryandesign (Ryan Carsten Schmidt)]

Replying to arno@…:

I'm not the maintainer. I just noticed that it was out of date and wasn't linking to libconfig.

What confused me was that you added the keyword "maintainer", which is supposed to mean that the maintainer filed the ticket. I'll remove the keyword.

The README actually specifies the -hr implementation of libconfig. I don't know that the newly fixed version would be incompatible, but it's probably best to just change it to a "port:libconfig-hr" dep.

Ok. My concern was that libconfig and libconfig-hr conflict with one another; only one or the other can be installed at a time. So if we had a set of ports X that depend on libconfig and another set of ports Y that depend on libconfig-hr, then you would not be able to install and use simultaneously a combination of ports from both sets. However, it appears that at present we do not have any ports depending on either libconfig or libconfig-hr so I guess it doesn't matter. And libconfig-hr does bill itself as a superior libconfig implementation so, if that claim is true, then we can certainly go with that.

[ryandesign (Ryan Carsten Schmidt)]

I committed the update in r96248. I simplified your modifications to the destroot phase somewhat and also installed the ChangeLog file in addition to the READMEs.

[fracai]

Thanks.

I, for some reason, thought "maintainer" was like "haspatch" and just indicated that the port had a maintainer. I have no idea why that made sense when I added the tag.