From RelEng meeting on Apr 17th 2019:

 #info ignatenkobrain and/or mizdebsk will comment on the changes they need in koji and we will proceed further based on the changes.

So, I am now considering to stop using Modularity because it is not improving, but rather opposite. My need here is to have one place where I could build all rust packages (the crates ones) and then build binary packages shipped to users on top of them. I also need to have latest RPM to build these packages.

I think most straightforward way would be to:

1. create rust-pool tag/target
2. make it inherit from f32-build (and keep updating it to rawhide every time we branch)
3. inherit all f30-build, f31-build, f32-build from this tag

The only problem here is that I won't be able to build rust apps directly in f30 yet since rpmbuild there does not support dynamic buildrequires..

Any ideas / suggestions / proposals?

@kevin @mohanboddu

Thanks for putting so much effort into our rust ecosystem @ignatenkobrain !

@ignatenkobrain Could we potentially revert back to regular packaging and leverage Koschei or OBS to resolve the full collection of dependencies before submitting from Dist-Git into Koji?

We could do that. As long as we have automation to build hundreds of packages without manual work and without waiting days, I'm fine.

An idea about how to build rust apps for Fedora 31. Collect all the build dependencies (incl. transitive) on Rust libraries. Buildroot override all the recent rawhide builds into the f31-buildroot (but create no update), built the app.

I understand that you've volunteered for dynamic BuildRequires, so you cannot apply this for Fedora 30, but it should work for F31 and further.

I'd really prefer to try and fix mbs if thats at all possible?

I don't like mixing rawhide packages in the f31 build root.

Another possibility is to build the rust libs in a side tag only, build the apps in that side tag, retag the app into Fedora. Never merge the side tag back.

@churchyard This means that not all the build inputs are published... ever. That's a huge problem for reproducibility.

This means that not all the build inputs are published... ever.

They are "published" trough Koji. Aren't they?

@churchyard But not in the repository, which means the Source RPMs are essentially impossible to use without a lot of work to download stuff from Koji. Mock won't work locally, for example.

Isn't that the case for the current modular way of doing this as well?

Hmm, you're right. I think @ignatenkobrain has been filtering them all out... :(

I'd really prefer to try and fix mbs if thats at all possible?
I don't like mixing rawhide packages in the f31 build root.

I agree.

Another possibility is to build the rust libs in a side tag only, build the apps in that side tag, retag the app into Fedora. Never merge the side tag back.

I like this idea (if not modularity). And we can provide the side tag for all the releases, and provide the acls to @ignatenkobrain to tag the apps back into the main tag (which I think he already does).

I like this idea (if not modularity). And we can provide the side tag for all the releases, and provide the acls to @ignatenkobrain to tag the apps back into the main tag (which I think he already does).

Let's do that? The Final freeze for F31 is in ~2 weeks, so better we start ASAP.

One problem I can think of is that the nomondular packages will need to somehow obsolete the modular packages and that is AFAIK not possible because dnf will exclude them.

So, the idea of trying to fix mbs is not one you want to try and do? Can we at least identify existing/current issues?

So, the idea of trying to fix mbs is not one you want to try and do? Can we at least identify existing/current issues?

Is there even anyone working on MBS? Even getting work done on Koji is like pulling teeth. Why would we expect anyone to be responsive to fixing issues in MBS?

I think this is moot now that https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches is approved?

Feel free to re-open if there's still something to do.