Opened 13 years ago

Closed 4 years ago

#30324 closed update (fixed)

cherokee: update to 1.2.29 and add new variants

Reported by: stahlstift@… Owned by: herbygillot (Herby Gillot)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: ryandesign (Ryan Carsten Schmidt)
Port: cherokee

Description

This is my first try to update a portfile. Please double check if I did everything correct.

Attachments (1)

cherokee.diff (2.9 KB) - added by stahlstift@… 13 years ago.

Download all attachments as: .zip

Change History (8)

Changed 13 years ago by stahlstift@…

Attachment: cherokee.diff added

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: haspatch added

Thanks for the update. Here are some observations:

  • If you wish to maintain the port, the maintainers field must be your complete email address (preferably in our obfuscated form). Only MacPorts committers, who have @macports.org email addresses, may omit the macports.org part and list just their handle.
  • The license field should read "GPL-2" if only GPL version 2 is acceptable, or "GPL-2+" if GPL version 2 or later is acceptable.
  • Why turn geoip and rrdtool support into variants? We want ports with as few variants as is convenient. Variants should only be added for inconveniently large dependencies (perhaps ffmpeg qualifies), or where there is a choice (e.g. MySQL 4 vs. 5).
  • If the ffmpeg variant is to stay, then the port needs to ensure that ffmpeg will not be used if the variant is not selected. Also, would ffmpeg suffice, or is ffmpeg-devel really required? If either would work, allow the user to use either; see #14540.
  • The two mysql variants have identical descriptions; the descriptions need to differ so the user can decide between them.
  • Why a "no_nls" variant? Why would anybody want to disable native language support?

comment:2 Changed 13 years ago by stahlstift@…

Hey ryandesign,

I thought you stop maintaining the port. I hope you want to be still the maintainer ;)

rrdtool got much depends which I don´t need for example at my devmachine. I didn´t know about that convention. So it would be better to make them default and let user like me the possiblity to -rrdtool?

I don´t want why anyone want to use no_nls - but the configure got the option.

comment:3 in reply to:  2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

Replying to stahlstift@…:

I thought you stop maintaining the port. I hope you want to be still the maintainer ;)

Actually I have never used, maintained, or had anything to do with this port before. I'm just responding to your proposed patch with some comments about how ports should generally be written.

rrdtool got much depends which I don´t need for example at my devmachine. I didn´t know about that convention. So it would be better to make them default and let user like me the possiblity to -rrdtool?

Ok, I see your point. rrdtool does have a lot of dependencies. It can be a variant then. But as I said, the port must take whatever measures are necessary to ensure that rrdtool does not get used if the user does not select the rrdtool variant, even if the rrdtool port is already installed. All you've done in the variant so far is add the dependency, which is insufficient. Investigate whether there are configure arguments, environment variables, or patches that would be needed to accomplish this.

Whether rrdtool should be a default variant is a separate question, and depends on whether "most users" would want this functionality or not.

I don´t want why anyone want to use no_nls - but the configure got the option.

That's not a good reason. Yes, configure scripts have many options, but most of them should not be exposed to MacPorts users. It's the job of the portfile author to choose good defaults, and possibly provide a few variants for one or two options the user might actually care to switch on or off.

comment:4 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Oh, and I also wanted to mention, though I see that rrdtool makes sense as a variant, libgeoip does not: it's just a single additional port which has no dependencies of its own which takes less than a minute to build on years-old hardware; no reason not to keep that enabled all the time.

comment:5 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to michael@…
Summary: Cherokee Portfile Update to 1.2.29 with new Variantscherokee: update to 1.2.29 and add new variants

Assigning ticket to new maintainer.

This ticket has been partly superseded by #33750 in which cherokee was updated to 1.2.101. The issue of whether to add more variants remains. The port already has a distressingly large number of variants; I would be more inclined to remove variants than add new ones.

Additional related variant/dependency concerns are filed as #33767 and #33768.

comment:6 Changed 5 years ago by mf2k (Frank Schima)

Owner: michael@… deleted
Status: newassigned
Version: 2.0.0

See #58384.

comment:7 Changed 4 years ago by herbygillot (Herby Gillot)

Owner: set to herbygillot
Resolution: fixed
Status: assignedclosed

In daed60864683925cef2999bfe3bcadbab25039fe/macports-ports (master):

cherokee: update to 1.2.204

  • use distfiles from Github as official site points to Github-hosted assets
  • use recommended checksum types
  • patch and configure to use $prefix/var/www as www root
  • remove all variants, add new variants for ffmpeg and LDAP
  • add Python 2.7 as lib dependency, also needed for build process
  • use automake/autoconf/libtool in build process

Closes: #30324
Closes: #33768
Closes: #44766
See: #33767
See: #43704

Note: See TracTickets for help on using tickets.