On Mon, 2020-09-28 at 17:33 +0900, Tristan Van Berkom wrote: > Format addition to junction elements > ------------------------------------ > Currently we already have precedent for overriding junction elements in > subprojects, this was mostly done in order to ensure that we can > synchronize subprojects which depend on common subprojects, such as to > explicitly ensure that both subprojects depend on the same version and > configuration of a subsubproject (diamond project dependency shapes). > > That said, I think an elegant way forward would be to simply allow > elements to also be specified in the overrides, instead of only > allowing junctions to be specified in the overrides. > > Following my illustration above, one might define the upstream.bst > junction element with the following: > > kind: junction > > overrides: > gtk+.bst: gtk-fork.bst > > > Thoughts ?
I think it's a reasonable generalization of the existing mechanism and there are scenarios where this is likely the best approach. The gnome- build-meta case seems like a good example as it makes sense to me that gnome-meta-build wants full control over all elements that are part of the upstream GNOME project, which includes GLib and GTK. However, in many scenarios working with upstream and/or forking the upstream project is still the better choice, in my opinion. E.g., if a downstream project author wants to add a configure option to an element, I wouldn't recommend overriding the whole element. Otherwise, all future changes to that element in the upstream project will be lost to the downstream project, without even a warning. If you create a downstream branch for the subproject, upstream updates to that element will be merged on the next rebase (or you get a conflict, which you can resolve), so you won't silently miss important upstream changes. I.e., I'm not opposed to adding this, however, we should keep recommending the existing two options for modifying subprojects for most use cases, in my opinion. Cheers, Jürg
