Mailinglist Archive: opensuse-packaging (97 mails)

< Previous Next >
Re: [opensuse-packaging] On how to improve Rust packaging experience for suse

On 11/19/19 11:22 AM, William Brown wrote:

On 19 Nov 2019, at 11:19, Simon Lees <sflees@xxxxxxx> wrote:

On 11/19/19 11:07 AM, William Brown wrote:

On 19 Nov 2019, at 11:04, Neal Gompa <ngompa13@xxxxxxxxx> wrote:

On Mon, Nov 18, 2019 at 7:32 PM William Brown <wbrown@xxxxxxx> wrote:

Okay, so when you do:

Project -> Repositories -> Add from a distribution -> select fedora 30

That only adds fedora 30 standard:

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

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.

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.


Simon Lees (Simotek)

Emergency Update Team
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

< Previous Next >