On Wed, Oct 16, 2019 at 8:56 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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. I'm getting increasingly worried by this recurring and very catchy "too fast too slow" phrasing. I have seen the topic of build-only dependencies come up often lately with pro-modules praising the ability to select the exact dependency tailored for their "stream" and the anti-modules blaming a lack of transparency and maybe other things I don't quite remember at this time of the day, before coffee. Being myself not happy with Fedora modularity, I'm also not a huge fan of the state of the "everything" repository, even before modularity happened. With the rise of languages like Go and Rust and their source-based tooling we end up with effectively "source binary packages" in the distribution that nobody besides other Fedora packages would use. I may have used yum in the past to grab and NodeJS dependency, but actual "node" developers will certainly use tools from the NodeJS ecosystem like npm. Your average developer doesn't sit under a waterfall and decides that they will only use dependency from Fedora repositories and impose themselves offline builds, they use whatever dependency solver their usual tool chain provides. So to me, a good middle ground would actually to start by introducing build-only dependencies. But instead of hiding them as the anti-modularity claim, have them in a in a new set of repositories: - fedora-build - fedora-build-debuginfo - fedora-build-source - updates-build - updates-build-debuginfo - updates-build-source While it may look like *more* repositories, this should actually result in less. In my suggestion, you would *move* build-only dependencies to a separate set of repositories. By having the build repositories disabled by default, it results in less metadata to process for the main `fedora` and `updates` repositories. This doesn't hide packages from end users, and only adds an extra step to access everything that has little value on a "production" system (my laptop for example). And besides amazing improvements when it comes to fetching metadata thanks to zchunk, I would also like to have in general less packages and less metadata because DNF doesn't do so well in memory-constrained environments. Once you have build-only repositories, we have new problems to deal with, like teaching the Fedora tool chain how to distinguish normal from build-only SRPMs (and I insist this should be all packages from an SRPM or nothing). But then with the *usual* compat guidelines we can have parallel-available build-only dependencies that don't need to be visible (by default) to end users. And thus, if a package maintainer faced an FTBFS caused by a dependency bump, we would have the opportunity to either try to patch and upstream a fix, or introduce a compat build-only package. However for the latter you would ideally need an exception from Fesco to avoid a tendency to solve FTBFS by freezing build-only dependencies instead of following the First principle. My couple cents, Dridi > > 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 _______________________________________________ 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
