New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #35489 (closed update: fixed)

Opened 10 months ago

Last modified 10 months ago

sslh - upgrade to 1.13b

Reported by: arno@… Owned by: ryandesign@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: macports@…
Port: sslh

Description

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.

Attachments

Portfile.diff (1.9 KB) - added by arno@… 10 months ago.
sslh Portfile diff

Change History

Changed 10 months ago by arno@…

sslh Portfile diff

comment:1 Changed 10 months ago by arno@…

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.

comment:2 Changed 10 months ago by ryandesign@…

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?

comment:3 Changed 10 months ago by 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.

comment:4 follow-up: ↓ 6 Changed 10 months ago by arno@…

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.

comment:5 Changed 10 months ago by arno@…

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'.

comment:6 in reply to: ↑ 4 Changed 10 months ago by ryandesign@…

  • Status changed from new to assigned
  • Owner changed from macports-tickets@… to ryandesign@…
  • Keywords maintainer removed

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.

comment:7 Changed 10 months ago by ryandesign@…

  • Status changed from assigned to closed
  • Resolution set to fixed

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.

comment:8 Changed 10 months ago by arno@…

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.

Note: See TracTickets for help on using tickets.