Mailinglist Archive: opensuse-packaging (97 mails)

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

On 11/19/19 12:56 PM, Neal Gompa wrote:
On Mon, Nov 18, 2019 at 8:58 PM Simon Lees <sflees@xxxxxxx> wrote:

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 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.

Generally Legal reviews should only need to happen the first time which
might make for a reasonable initial delay, after that it should just be
review team reviews. If SUSE starts to require significant parts of the
Rust stack and this starts to overwhelm the current review team it would
be reasonable to expect SUSE to add additional resources to the review
team so in the long term this isn't something that isn't unsolveable.


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 >