On Wed, Oct 16, 2019 at 10:49:29AM -0700, Kevin Fenzi wrote: > On Wed, Oct 16, 2019 at 10:02:12AM +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. I think we're talking about two different things here. The proposal is to allow the buildroot to be arranged in some specific way, but does not say whether the stuff that is built will be *correct*. E.g., as you say below, if the built rpm has a dependency that cannot be satisfied, the rpm will not be installable. This is where gating comes in. I think rawhide gating would an excellent way to verity that the rpm is *correct*, but it is outside of scope of the proposal. But let's compare it with two scenarios: a) I build an rpm (non-modular) right now, and I declare a Requires: that cannot be satisfied. End result: an rpm that FTI. b) I build an rpm as part of a module, but it requires some old version of the library. End result: an rpm that FTI. Of course with modules the situation is more complicated, because the module might try to bring in the rpm with some old library, but that causes problems and is currently forbidden, because this breaks other packages. c) I build an rpm in a side tag with older packages pulled in. If this results in installation-time dependencies on those packages, FTI. So there really isn't much difference with the proposal: the packager still needs to make sure that the resulting rpms are installable. The proposal makes it easy to pull older rpms during build, solving *part* of the "too fast, too slow" problem. If older versions they are also necessary for installation, compat package would need to be used. > So... this is rawhide multibuild gating with some more stuff on top of > it, unless I am misreading? (ie, much of this is already being > implemented as part of that). And the stuff on top has to do with > modules interaction. > > I don't understand how the 'newer or older' builds would work though. > > Say I built my rawhide foo stack against openssl-100. I merge it back, > either it doesn't merge openssl-100 and all my foo that links against it > is broken, or it does and it conflicts with the existing openssl version > and breaks everything else. Or are you assuming no runtime older/newer? > How is that checked? I guess if we have tests for it, gating could stop > it. > > This is pretty much exactly how multibuild rawhide gating will work > (very soon now!) Yes, that is excellent news, in the scope of this proposal and also independently of it. 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
