On Wed, Oct 16, 2019 at 09:06:19AM -0700, Adam Williamson wrote:
On Wed, 2019-10-16 at 10:02 +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> I submitted a Change for wrangling today, but I'm also putting it here
> for discussion:
>
https://fedoraproject.org/wiki/Changes/OnDemandSideTags
>
> This is intended to be an alternative to modularity, in the sense
> that it allows some rpms to be built against older or newer versions
> of dependencies, but the details of this process are invisible for
> end users, who get only normal rpms.
>
> The text is too long to paste here, so please take a look on the wiki.
> I'm especially interested in feedback if this would work for *your*
> use case and make *your* life easier.
To me it looks like it'd make some things harder. It makes reproducing
builds very difficult, as you need to dig through logs to figure out
exactly what build environment the packager set up.
That is true. But that is a general issue inherent in any
modularity-like setup where you allow people to tweak the build root.
I think that the answer to this is not to disallow this, but to make
it more transparent. In principle, koji could provide the information
which packages were installed in the build root as structured data.
A similar thing occurs with "dynamic buildrequires": and any package
can request other packages dynamically, so recording and retrospecting
the build root becomes quite important.
I already kinda hate dealing with buildroot overrides, but at least
those are identifiable artifacts you can relatively easily get a
start/end date for. This is like buildroot overrides on steroids in
some ways (though better in one way - it doesn't affect *every* build).
Yeah, I think this would mostly replace buildroot overrides:
usually we create them to rebuild some specific packages, and in this
proposal, it'd be nicer to just rebuild everything in the side tag.
If some of the builds don't go as planned, just discard the whole
thing and start over.
Zbyszek