On Mon, Nov 18, 2019 at 8:58 PM Simon Lees <sflees@suse.de> wrote:
On 11/19/19 11:22 AM, William Brown wrote:
On 19 Nov 2019, at 11:19, Simon Lees <sflees@suse.de> wrote:
On 11/19/19 11:07 AM, William Brown wrote:
On 19 Nov 2019, at 11:04, Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Nov 18, 2019 at 7:32 PM William Brown <wbrown@suse.de> wrote:
Okay, so when you do:
Project -> Repositories -> Add from a distribution -> select fedora 30
That only adds fedora 30 standard:
https://build.opensuse.org/repositories/Fedora:30
But not update. This is why all the f30 builds I have are failing. This seems like a bug or error to me.
It is done this way to minimize automatic rebuilds by default, as new updated packages in the repositories will trigger rebuilds. If you want updates, just change "standard" to "update" and call it gravy. Most don't require this, but your Rust case probably will.
For what it's worth, openSUSE Leap targets are similarly set up.
This is really counter intuitive to anyone who is reasonably inexperienced at packaging (IE me), which is probably another barrier to getting people to do tasks like this. It could be improved both as a default (include updates because that's the expected behaviour) or via UI (offer updates as an option in the distribution menu, or make it easier to alter standard -> update in the respository list).
One reason that it is done like this by default is because core SLE / Leap packages shouldn't be break API/ABI for updates, so in the vast majority of cases building against standard is fine and saves huge amounts of resources on obs. You are only really hitting this issue because you are working with one of the few echosystems that as you say doesn't follow our traditional model.
Ecosystems are changing, and less and less are following the traditional model - I think we can't keep treating them as exceptions, because this will become the norm for many languages.
So how can we improve this? How can we make rust a first class language for our platforms so that we can keep including relevant and modern tools in our platforms?
This is not just a tooling problem but also a process problem, the Haskell team have managed to script there entire process, there scripts can automatically push updates too there 2500 packages. This then revealed a different set of issues where our manual package review team and legal team didn't have enough manpower to regularly deal with the extra 2500 requests and I think for now the end solution was to cut back and just have the most useful packages in factory and the rest in a devel repo.
For Rust crates, we can easily have similar automation. We're still building up the set of crates, but because of the whole manpower problem with reviews, it's going to be a rough time.
So it has been shown that atleast with one platform once the core is there and working, handling the frequent updates of various packages can be largely automated at least for tumbleweed as long as they are capable of doing offline builds.
For SUSE there is definitely a discussion that should be had around whether we should promise binary compatibility for the whole stack but that's a discussion for SUSE's product managers etc.
The bottleneck is almost entirely in the review process. We can do large updates easily enough. The review process does not handle large stack updates well. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org