[MacPorts] #60044: gpsd: python34 variant depends on nonexistent py34-serial port

[MacPorts]

#60044: gpsd: python34 variant depends on nonexistent py34-serial port
------------------------------+-----------------------
  Reporter:  ryandesign       |      Owner:  michaelld
      Type:  defect           |     Status:  assigned
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:  2.6.2
Resolution:                   |   Keywords:
      Port:  gpsd, py-serial  |
------------------------------+-----------------------

Comment (by fhgwright):

 Replying to [comment:4 ryandesign]:
 > Replying to [comment:3 fhgwright]:
 > > If it's just about distfile mirroring, why is it paying attention to
 dependencies at all?  With the possible exception of fetch dependencies
 (if they even exist), dependencies should be completely irrelevant for
 what's essentially a version of "port fetch".
 >
 > The buildbot uses MacPorts base to do the work, and I guess MacPorts
 base ensures that a port's dependencies exist before doing any of the
 phases.
 > And yes, there is such a thing as a fetch dependency (`depends_fetch`).

 I just did a test where I verified that "port fetch gpsd +python34" (after
 "port clean --all gpsd" of course) has no problem fetching the distfile
 for gpsd with py34-serial as a nonexistent port.  So the mirroring stuff
 is clearly trying to enforce dependencies beyond what a normal port
 command would do.  I don't see the value in this.

 > > Indeed providing *all* variants would be problematic, though I think
 I've seen isolated cases of more than one.  Criteria for inclusion might
 be based on popularity of the variant, time required to build from source,
 and size of the binary archive.  It would make sense to boost the priority
 of anything that can't be built from source for an upgrade without manual
 intervention, such as anything involving the dreaded libunwind-headers, or
 poppler, or the ld64 stuff that Ken's been talking about.
 >
 > I don't think we have any of the data that would be required to do any
 of the above, except for variant installation statistics which are
 available on ports.macports.org but only for those very few users who have
 opted in to send us their stats.

 Certainly the (relative) build time and the archive size are available
 from the buildbots.  Ports which can't be built or upgraded without manual
 intervention would probably be best handled by flagging them explicitly in
 the Portfile.

 There is a form of information available about variant usage that's both
 better in some ways and worse in some ways than the opt-in reports from
 users.  Every install or upgrade without -s (or equivalent) attempts to
 fetch a binary archive before resorting to building from source.  The URL
 of the archive being requested contains the port name, the version, the OS
 version, the CPU architecture, and the variants.  So all this information
 probably already exists in the server logs without any action on the part
 of the users, though it's only sampled at install/upgrade time, and absent
 with -s.

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