[MacPorts] #63466: libvirt @7.6.0: libvirt-lxc.0.dylib provides version 0.0.0

[MacPorts]

#63466: libvirt @7.6.0: libvirt-lxc.0.dylib provides version 0.0.0
-------------------------+------------------------
  Reporter:  inflatador  |      Owner:  ryandesign
      Type:  defect      |     Status:  accepted
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.7.1
Resolution:              |   Keywords:
      Port:  libvirt     |
-------------------------+------------------------
Changes (by ryandesign):

 * status:  assigned => accepted
 * priority:  Low => Normal


Comment:

 The creator of any library is free to define its versioning scheme.
 6007.0.0 is a valid library minor version number, as is 0.0.0. It is the
 responsibility of the developers of the project to exercise care to ensure
 that their library versions proceed in a sensible manner, for example to
 ensure that the library minor versions do not decrease from one release to
 the next. Unfortunately, the developers of libvirt appear not to have
 exercised that care in this case.

 What appears to have happened here is that the developers of libvirt
 decided to switch from the autotools build system to the meson build
 system. For a time both build systems were offered and MacPorts stuck with
 the autotools system since that was less work than switching, but then
 libvirt deleted its autotools build system so we were forced to switch.
 This happened when the port was updated to version 7.0.0 in
 [50f6b87e76adfc829c92802d3ec8b91aab53ca8c/macports-ports]. autotools
 (libtool) has a very particular way of handling library version numbers,
 so it would be incumbent upon the developers of any project switching from
 libtool to some other library build system to ensure that the existing
 library versioning scheme is preserved. The developers of libvirt didn't.

 This is unfortunately an extremely common mistake made by I would guess
 most projects that switch from autotools to something newer, and there
 have been a lot of projects over recent years that have switched from
 autotools to cmake or meson. Unfortunately, usually by the time the
 mistake is noticed it has been published in a release of the software and
 the developers are often uninterested in fixing the problem.

 I don't see a bug report filed about this with the developers of libvirt.
 If you would like to file a bug report with them so that they might return
 to the previous library minor version numbering scheme in a future
 release, the URL to do so is https://gitlab.com/libvirt/libvirt/-/issues.

 If they will not fix their library versioning in the foreseeable future,
 then the workaround that we probably have to employ is that every port
 that links with a libvirt library that has not had its version or revision
 increased since we updated to libvirt 7.0.0 should have its revision
 increased to rebuild it against the new (lower) library minor version
 number. If the software with which you encountered the error was not built
 by MacPorts, then you will need to rebuild it from source separately.

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