#6889 Changes/Packaging Rust applications and libraries
Closed: Fixed 2 years ago Opened 2 years ago by ignatenkobrain.

https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_libraries

Release Engineering are one of key persons in implementing this change because tools should be ported to DNF, with rich operator should be supported from tools (speaking as DNF team member, it should just work).

As a creator of change proposal and member of DNF team, I will help rel-eng as much as I can.


Metadata Update from @mohanboddu:
- Issue tagged with: changes

2 years ago

@mohanboddu I tihnk this is missing f27 label... ;)

Metadata Update from @mohanboddu:
- Issue tagged with: f27

2 years ago

Metadata Update from @mohanboddu:
- Issue tagged with: change-ack

2 years ago

We ack this requires releng work and currently we are working on porting our tools to dnf.

Its a huge change and it needs more coordination with the fedora tooling and also more with internal teams on how things are built, delivered and tested and everything else that gets effected.

Metadata Update from @ausil:
- Issue untagged with: change-ack

2 years ago

@mohanboddu sure, I wrote this in the beginning ;) do you want me to take any actions now or just wait until someone from rel-eng will contact me? Ideally, we need this earlier than final freeze so we have time to submit package reviews, approve them, import them and such.

@ausil @mohanboddu:

What the heck? Why was this untagged? All the tooling should be in place now, with pungi supporting DNF as a depsolving algorithm. It should have been started to be used with Rawhide after the porting was done during Fedora 26 development cycle. @ignatenkobrain has even offered up his services to help speed up any remaining issues through the Fedora 27 development cycle.

:angry:

we need to ensure that all the systems dealing with packages are able to cope with the change. This touches on every piece of the delivery pipeline, it needs input from QA, and infrastructure at the least to make sure we have plans to cope properly.

@ausil
1. Who and when will provide this information?
2. Who and when will provide information what needs to be done in order to accomplish this change?

P.S. F27 release cycle is quite short, so I need to know precisely who and what will be doing so I can offer my help and to not slip this change to F28 just because someone didn't pay attention to this.

@adamwill @tflink what state are the QA systems for ensuring that they can all read rpms with rich dependencies.

@kevin same for infra, likely every system in the build and delivery pipeline that runs rhel will need to be upgraded.

Well, lets see:

  • koji builders are fedora - fine
  • koji hubs are rhel7 - would need switching to fedora
  • rawhide/branched composers are fedora - fine
  • bodhi-backend01 is fedora - fine

so it sounds to me like the hubs would be the main thing. Of course all the tools on those things... koji, pungi, bodhi would need support.

@kevin note that we need to support here new rich dependency which is coming within F27 itself. Probably we will need RPM 4.14 somewhere on builders (mosr probably). I'm volunteering to maintain special RPM 4.13 (current in all fedoras) which support that kind of dependency if required.

I'd really like to avoid doing that if we can. We have done that in the past and it was a big pain.

Well, lets see:

koji builders are fedora - fine
koji hubs are rhel7 - would need switching to fedora
rawhide/branched composers are fedora - fine
bodhi-backend01 is fedora - fine

Signing bridges are RHEL7 - would need switching

so it sounds to me like the hubs would be the main thing. Of course all the tools on those things... koji, pungi, bodhi would need support.

This Change has been deferred to F28.

@puiterwijk signing might just work... but we need to try-and-see..

@kevin, when would be good time to see what breaks?

Signing bridges shouldn't care, since RPM shouldn't be processing the dependency header information... It's handled rich deps packages so far, I imagine it can handle this too.

@puiterwijk signing might just work... but we need to try-and-see..
@kevin, when would be good time to see what breaks?

Well, ideally we would wait for a less busy day where rawhide compose finished fine.
Then you push a package, we make sure it's signed and then fire a new rawhide compose.
If things blow up we untag it and fix them and try again later.

Possibly after flock?

Possibly after flock?

Would work for me, just let me know once you are ready! :wine_glass:

Just to update this ticket we did test rich deps in rawhide and things all seemed to work just fine. Composes worked, koji was fine, pungi was fine with it, etc.

Next step is to complete the 'replace mash with pungi' in bodhi so we can push updates of these things. That work is ongoing...

Metadata Update from @mohanboddu:
- Issue untagged with: f27
- Issue tagged with: f28

2 years ago

All the work to support Rust applications and libraries are landed in rawhide(F28).

Closing the ticket as no more work is needed.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata