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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
