 So the question is who should want to attend this talk and it's really all about packaging rust projects for fedora and So it's people everything I'm going to talk about is sort of how to manage upstream rust projects So they behave well when you're packaging for fedora and in general So it's just generally people who have that on their minds. You should be interested in this talk and And Who am I my name that what you should call me as moherne if you want to I'm the stratus team tech lead and I do a lot of the fedora updates for the rust packages That are part of the stratus project, although I don't think I actually originated the fedora package of any one of them And I do a lot of the upstream packaging of the rust packages too So that's my experience. So I thought about it and And that's what I'm talking about it today so ask questions as Much as you feel like But obviously we've already had technical difficulties. So we'll see if there are any more that cause problems But I'll try to keep a bit of an eye on the chat chat okay so My goal is just to manage the dependency requirements for all the Packages in the project so that they can be packaged correctly upstream so that they're correct and so they're safe for fedora And so of course, you might wonder what those vague words mean and I'm going to define those Immediately so before though I have to say something about versions and version requirements Because they get muddled when we talk about them all the time because they're sort of similar looking and so Aversion is just that thing a version of a single concrete entity sort of a snapshot of your project But the version requirement is a way of specifying a whole range of versions that you consider acceptable and for those who aren't familiar with rust Rust cargo files uses the special carrot syntax, but that's just sugar for a compound Specification indicating greater than or equal to something and less than that other thing Okay, so here's the complicated picture of fedora packaging And the things that influence it and you have to imagine that those greenish yellow slabs are some versions of a package on crates.io and We need to have at least some version in order to compile because we use say some methods that aren't defined until this version 2.1.0 and For whatever reason maybe there was a bug fix that we wanted we specify using this carrot syntax that anything 2.1.1 or above up to 3.0 is good and so When we compile our package on in RCI, it's kind of a toss-up which Version of the create will actually use so there are five possible versions of the create create. We might be running our tests on and Then the highest one package in fedora in this picture is 2.2.1 and We'll also mention that there's a CVE against 2.2.0 for some reason and that's why 2.2.1 was created no doubt, but in this picture everything is good So that's the point we specify this carrot 2.1.1, but that works with fedora And it's high enough so that everything will compile. So this picture is a reasonably happy situation And so now I'm going to go on to Where problems arise? Okay, so what we don't want to do is Specify this would be unsafe specify in our cargo.toml file a Dependency version or rather requirements such that it can't be sped can't be satisfied in fedora now So the way fedora works Fedora packaging works is that every package that you're the package depends on is required to also be packaged in fedora and And so for those who are used to using in their rust Packages cargo.lock. I'll just say the fedora packaging process throws away the cargo.lock file entirely and then has its own way of trying to find fedora packages that satisfy those version requirements specifications and if These are not satisfied Fedora packaging fails and then you have a problem So this is a picture of a bad situation for whatever reason this project is specifying the carrot 2.2.2 Specification that's higher than what is packaged in fedora And so even though upstream is fine and everything's cool when we go to package in fedora We'll have a problem. Packaging will simply fail and And so some people might say that's not a big problem because you can always just patch Your cargo.toml file before you do the packaging and so forth and so on and in a sense That isn't but we'll see I'll discuss sort of in more depth What this is all about here So So you can deal with this problem that I just showed you a picture of In a bunch of ways I Agree with that thing. It's exactly what happens in Rust 2 great actually Let me I can talk about that in more detail. I think but anyway, so here we are in fedora And we don't want to get into this bad situation. There's a couple ways. There's a few ways we can do it One way is to be the packager So if you're the packager of the dependency if you're the upstream developer and the fedora packager of the dependency You don't have a problem. So I was gonna mention that there's gonna be a talk tomorrow But in that you can discuss how to Put things inside tags maybe and since you have total control over the The fedora package and upstream you can manage how those all go in together and you're good So it's not something I want to even bother to talk about here because the problem is covered But it's also not like a scalable solution. You can't be responsible for every package in fedora So another way To make sure that you don't get this problem is to explicitly coordinate with the fedora packagers of all your dependencies But that's a pretty high friction thing to do and it's not it's more It's sort of trouble that you don't want to take on unless it's something you actually want to do So what we do is we automate checks of the fedora repos so that our direct dependencies Lag what's available in the fedora releases? We have a script. It's a python script. We run the script in our CI So that we will immediately find out if in cargo commo We have a spec that can't be satisfied in fedora If it is necessary for our direct dependency version to exceed what is available in fedora If we really really need that then we fall back on either of the two Options above that I crossed out We also run the script nightly and it tells us if there's a new Semantically incompatible release of some dependency in fedora and then whenever is convenient. We move up to it So that's the whole story of that one and so I'm just going to sum up how this works So because we do this we're put putting an upper limit or a downward pressure on our dependency requirements and What we would encourage people to do is to put this Infrastructure in Ross is sorry in their upstream Packages and not in fedora If they're concerned about making packaging easy in fedora, okay, so to go back that's the safety for Dora as I define it but Correctness for upstream is a different idea entirely and This correctness as in the picture that I showed you earlier puts a lower limit it pushes things up And its place is is also an upstream development and re-sleasing But it's not actually really so fedora specific although it was motivated by some of our fedora packaging concerns Okay, so this is a picture of a mistake So here we specify the carrot 2.1.0 dependency in cargo.tomo But we really need the 2.2.3 Version in order for our code to compile We don't find that out doing CI Because the 2.1.0 specification allows all six of these possible Versions of the crate and by the time we added the dependency on the method or the feature that was in 2.2 .3 We were already running against that version in all our CI So we never knew it and we packaged everything up happily and Then it turned out that it wouldn't that our mistake would be caught by fedora packaging Because in this picture again in the diagram fedora packaging only goes up to 2.2.1 So fedora packaging satisfies correctly What we say is true But then our program can't compile and then we have a problem an unpleasant surprise Okay, so how do we address this? Well one way is to aggressively boost our direct event dependency requirements whenever a New version comes out and that way what we say we need is never going to be lower Than what we're using that's kind of aggressive and One way of course is to be slightly less aggressive, but only to boost to the highest that fedora supports But we're actually interested in being Correct for a For for a broader set of downstream users But not not really just fedora, but all these people who might be packaging and so what we want to do is specify The lowest specification That actually works with our code So what we do in this case is we run a script. It's another python script that runs cargo update until every direct dependence until The dependency that we're actually running and running against is the lowest one that is compatible With the version specification that we have then we build the project now that every all these values are actually down and If the build if it fails to compile then Clearly the dependency that we specify is too low and The compiler error will helpfully tell us which of these dependencies are too low With a little insight Okay So this approach has been working actually fairly well for us for For a year or so, but when I was writing up this talk I noticed the Flaws in it and so I'll just mention those one of the flaws of the approach is that our scripts are written in Python not in rust and they actually says not just rust boosters and they actually should be written in rust because then they would take advantage of the appropriate parsing and Data structures in the cargo metadata and semper crates which match how cargo actually understands stuff Let's see So the other thing is They don't act there aren't any actually general in the way that they calculate the lowest version that satisfies the requirements and I've actually had some ideas on that problem that I was coming up with but The reason I only thought about it recently while I was working on this talk is it's never been a problem for us in the whole last year Because we use those carrot specifications and we assume they're there and because if there's an audit failure, which might Encourage us to have a not equals Part of the specification like skip this thing Then we actually don't use it. We just go usually we have always just bumped our requirement above The version that has the CDE so That concludes my talk and barely in time So I'm actually going to respond to Fabio's one remark cargo minimal versions was tried and failed already So this is what I you know, I hope this would solve the problem a long time ago But the problem is it tries to force everything every transitive dependency down to the lowest possible and In order to solve our problem. We only wanted to tweak the ones that are package Specifically Directly requested So yeah, cargo minimal versions was tried and would not yeah would not solve our problem Okay, so that there's a question in a QA, which is just a Very basic question really where should I start if I want to package a rust app in Fedora Linux? And I would say a good place to start is if you can go to the workshop that's being held tomorrow that Fabio is is going to give because that's gonna My understanding is that's going to start from the beginning and should answer a lot of questions Bye everybody