Added review as a way to inform you that building for Leap 15.3 is possible
with rust >= 1.46.
But version 1.56 seems to come from the update repository, while the security
project is configured to use "standard" what might not include updates.
Your packaging proposal with "cargo-packaging" would need it to be either included
in Leap or the spec file has to get some conditionals to work with new and old
approach depending on distro.
I'm not sure about how you want to approach the standard vs update spilt though. The reason "update" normally isn't added as a repo on devel projects is to prevent builder churn, since update changes more frequently which would cause projects to rebuild more often. By pinning devel projects to standard, the devel projects don't rebuild as often, and then are given a "final" rebuild when they are accepted to the final repo. However, rust updates will always come through the "update" channel from now, means that if we have a project with a higher MSRV we'll need to have update available.
For now, if it's working we can leave things "as are", and then in leap 15.4 once 15.3 is EOL we can come back to cargo-packaging since it then should be part of "standard". It's not a critical thing though, it just allows a bit of convenience for packagers and from my part as the "rust stack".
I'll need to have a talk to the smarter OBS people and work out with them what the right answer is here. :)
I'm not sure about how you want to approach the standard vs update spilt though. The reason "update" normally isn't added as a repo on devel projects is to prevent builder churn, since update changes more frequently which would cause projects to rebuild more often. By pinning devel projects to standard, the devel projects don't rebuild as often, and then are given a "final" rebuild when they are accepted to the final repo.
Thank you for the explanation. This makes sense.
However, rust updates will always come through the "update" channel from now, means that if we have a project with a higher MSRV we'll need to have update available.
So users who want rsign2 in Leap will have to build in a separate project
with updates enabled.
To support this scenario, building without cargo-packaging should be
possible until Leap gets it via updates or reaches EOL.
For now, if it's working we can leave things "as are", and then in leap 15.4 once 15.3 is EOL we can come back to cargo-packaging since it then should be part of "standard".
Sounds like a good plan.
It's not a critical thing though, it just allows a bit of convenience for packagers and from my part as the "rust stack".
Thank you for pushing Rust in openSUSE, firstyear!
I'll need to have a talk to the smarter OBS people and work out with them what the right answer is here. :)
If something changes, I'm interested to hear the results.
But with your reasoning from above, not having updates in the devel project
makes sense, although i'm wondering why SLE_15_SP3 builds succeed while
Leap 15.3 fails.
@firstyear
Added review as a way to inform you that building for Leap 15.3 is possible with rust >= 1.46.
But version 1.56 seems to come from the update repository, while the security project is configured to use "standard" what might not include updates.
Your packaging proposal with "cargo-packaging" would need it to be either included in Leap or the spec file has to get some conditionals to work with new and old approach depending on distro.
Or perhaps some other solution?
I'm not sure about how you want to approach the standard vs update spilt though. The reason "update" normally isn't added as a repo on devel projects is to prevent builder churn, since update changes more frequently which would cause projects to rebuild more often. By pinning devel projects to standard, the devel projects don't rebuild as often, and then are given a "final" rebuild when they are accepted to the final repo. However, rust updates will always come through the "update" channel from now, means that if we have a project with a higher MSRV we'll need to have update available.
For now, if it's working we can leave things "as are", and then in leap 15.4 once 15.3 is EOL we can come back to cargo-packaging since it then should be part of "standard". It's not a critical thing though, it just allows a bit of convenience for packagers and from my part as the "rust stack".
I'll need to have a talk to the smarter OBS people and work out with them what the right answer is here. :)
Thank you for the explanation. This makes sense.
So users who want rsign2 in Leap will have to build in a separate project with updates enabled. To support this scenario, building without cargo-packaging should be possible until Leap gets it via updates or reaches EOL.
Sounds like a good plan.
Thank you for pushing Rust in openSUSE, firstyear!
If something changes, I'm interested to hear the results.
But with your reasoning from above, not having updates in the devel project makes sense, although i'm wondering why SLE_15_SP3 builds succeed while Leap 15.3 fails.
No problem, thanks for your feedback!
I'm not sure about the SLE_15_SP3 build, I wonder if it's a combo standard/update repo or similar? I'll have to look into that....