[MacPorts] #62984: freeciv @2.6.4_0: propose a major restructure to provide all 12 clients and utilities

[MacPorts]

#62984: freeciv @2.6.4_0: propose a major restructure to provide all 12 clients and
utilities
---------------------+--------------------
  Reporter:  JDLH    |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by jmroot):

 This looks reasonable in general.

 Replying to [ticket:62984 JDLH]:
 > With no variants, the '''freeciv''' base port will not include a client,
 so one can host games, but not play them. I could make one variant a
 default, if the user doesn't specify any. Or, I could use `pre-configure`
 code to require at least one of the variants, so that the port always
 delivers at least one GUI client app for playing games.

 The GUIs should be provided as subports, not variants. Dependencies
 between the subports could be handled a few different ways, GUIs depending
 on base or base depending on a GUI, but I think the best way would be:
  * `freeciv` is a stub port (installs as close to no files as MacPorts
 allows), and depends on `freeciv-base`.
  * `freeciv` has a variant for each GUI, which adds a dependency on one of
 the GUI subports. One is on by default.
  * Each of the GUI subports, like `freeciv-gtk3`, depends on `freeciv-
 base`.

 That way, a user gets a fully-functional GUI installation whether they run
 `port install freeciv` or install one of the GUI subports directly, and
 the other GUIs are relatively easy to discover from `port info freeciv`.

 >  sdl client:: drop in version 3.0.x. But, it looks to me like it was
 dropped prior to version 2.6.4. The present '''freeciv''' portfile selects
 the sdl client over the sdl2 client for `(${os.major} <= 10)`, but
 upstream no longer supplies this client. Macports users on this OS cannot
 use freeciv, I guess.

 The release notes seem to imply that SDL1 support is still available in
 2.6.x. But the freeciv port seems to be failing to build on many older OS
 versions, including quite a few that use SDL2, so that would probably need
 to be fixed to clear this up.

 > This structure lets Macports users get the most usable clients from
 upstream, '''freeciv-qt''' and '''freeciv-gtk3.22'''.

 The downside of those GUIs is of course more dependencies. But making them
 available is definitely good.

 > I'm concerned that this change will surprise present users of the
 '''freeciv[-x11]''' ports. They will need to specify variants which
 weren't necessary before. The port '''freeciv-x11''' goes away. What is
 the right way to announce this proposal, and gather feedback?

 You would keep `freeciv-x11` around as a stub port that sets `replaced_by
 freeciv-gtk2`, for at least a year.

 > What is a good way of determining the exact list of ports on which each
 of these clients depends? I know they all build on my system, with its
 2000+ ports. But I don't see an easy way to determine the minimal set of
 ports required.

 You could build with `-t` (trace mode) and see what breaks and what files
 are hidden.

-- 
Ticket URL: <https://trac.macports.org/ticket/62984#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS