This also updates a bunch of its dependencies to enable the update,
and gets rid of libhif because upstream stopped maintaining it as
such, instead using it internally in other projects until they can
agree on an interface for it. Nothing seemed to be using libhif so
I'm not too concerned about removing it.
This reverts commit 8f07d4bd780a24dcf33be46d8cbfc6163fcdde0e. The build
failure blocking this package has been fixed in the meanwhile. Thanks to
@basvandijk for the heads-up.
(cherry picked from commit 56d033ac1b00a8b29bc29589312d2f5024656bd3)
We are currently carrying a number of vala versions where each version
is essentially just a copy of the earlier version.
This PR gets rid of a ton of duplication and uses a standard builder.
Secondly, we add a definition for the latest vala 0.34.1.
Lastly, we add a generic "vala" that refers to the latest stable
version.
I have tried changing the definitions for "simple-scan" and "valum" to use
the latest vala version and they at least compile OK so I'll try a
massive sed job to replace all the definitions later to simply use the
latest version through "vala" instead of specifying a version directly.
According to upstream:
"Well-maintained packages are expected to always build with the latest
stable Vala version."
Maybe this means that my generic builder is then no longer necessary. Oh well...
I added myself to the maintainer array for vala although I have no
interest in the language - this was purely a nix exercise for me but I
thought it was reasonable to be the one to clean up the mess if this has
side effects...
Cc: @antono and @lethalman
This reinstates the libSystem selective symbol export machinery we used
to have, but locks it to the symbols that were present in 10.11 and skips
the actual compiled code we put into that library in favor of the system
initialization code. That should make it more stable and less likely to
do weird stuff than the last time we did this.
