Created attachment 218756 [details] Patch I would like to make OPTIONal the run-dependency of glib20 on python, with a default that keeps the current status. The reason is that many packages depend on glib only for its shared libraries, and it is unconvenient to have to install 100MB of python just for that. If MAINTAINER agrees, there are two approaches: 1. just make the run-dependency optional This is what is currently implemented in the attached patch. The plist does not change so it's still possible to install python later to run glib-genmarshal and friends. 2. make the run-dependency optional and skip the installation of anything that relies on python Perhaps safer, perhaps overkill given that python continues to be a run-dependency by default and turning that off means you know what you are doing. However, if you prefer this approach, I'm prepared to implement it.
Moin moin What about the python scripts that are installed by the port -- are all of them only required for development? mfg Tobias
These scripts are installed unconditionally. Some of them, particularly gdbus-codegen, are used by consumers in their build processes. Making the run dependency optional would not have any meaningful effect, and may even cause build breakages for those not running default options.
Most (all) of the python bits are related to codegen. As I proposed, I can skip installing any of those files in the non-default configuration. Or we could package glib-codegen separately and try to adjust dependees accordingly.
Do we (want to) guarantee that in general non-default options don't break dependencies/dependees?
There are no meson options to not install them. They are not designed or intended to be separated. And yes, we should guarantee that non-default options not break consumers to the best of our abilities.
(In reply to Charlie Li from comment #5) It's not an issue if meson doesn't provide options for that: we could list them conditionally in pkg-plist. As per "They are not designed or intended to be separated.", I can certainly see the case for wanting to install the glib shared libraries because they are a dependency for something, without wanting to bring the whole python bundle with me. I'm ok with keeping my local patches, if a non-default "you know what you're doing" option is too much of a risk for gnome@, but I think making the ports finer grained would be a benefit. /me waits for authoritative answers.
Ehm, s/gnome@/desktop@/
(In reply to Pietro Cerutti from comment #6) > It's not an issue if meson doesn't provide options for that: we could list them conditionally in pkg-plist. Not acceptable, because consumers' build processes specifically look for and execute them as regular binaries, for example x11-toolkits/gtk30: http://beefy6.nyi.freebsd.org/data/122amd64-default/565091/logs/gtk3-3.24.24.log If you truly feel strongly about making the python bits optional, take it up with upstream.
(In reply to Charlie Li from comment #8) I agree, however I don't expect much traction upstream, they seem rather more interested in moving towards Python than away from it. For example: https://gitlab.gnome.org/GNOME/glib/-/issues/1859
(In reply to Pietro Cerutti from comment #3) Moin moin with hat desktop@: * Splitting the package is unlikely to happen until sub-packages are a thing. mfg Tobias
Thanks Tobias, I'll close this then.