Re: Proposal: Replacing elements through junctions

[Jürg Billeter <j...@bitron.ch>]

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

Re: Proposal: Replacing elements through junctions

[Tristan Van Berkom <tr...@codethink.co.uk>]

Hi,

On Tue, 2020-10-06 at 10:24 +0200, Jürg Billeter wrote:
> On Mon, 2020-09-28 at 17:33 +0900, Tristan Van Berkom wrote:
[...]
> 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.

+1, I certainly agree.

I think it is worth an `.. attention::` block in the docs around this
feature to explain the benefits and downsides of this workflow, and
explain what scenarios are more and less suitable for it due to those
tradeoffs.

Cheers,
    -Tristan