#11233 Automation of request-repos in flatpaks namespace
Opened a year ago by yselkowitz. Modified a year ago

  • Describe the issue

While RPM repo creation is now automated (mostly), it seems response times for exceptions (iow replying valid to the bot) has actually slowed. Perhaps the mass rebuild has something to do with that, but it would be helpful if we could at least minimize the number of requests which require human intervention.

The Flatpak SIG is just getting started, and there are going to be a lot more repo requests in the flatpaks namespace going forward. Right now, every single one is treated as an exception. To avoid that, could some criteria be used to auto-approve these, e.g. (in psuedocode):

(namespace MATCHES "flatpaks") AND (repo EXISTS in rpms namespace) AND ((maintainer IS-MEMBER-OF flatpak-sig) OR (maintainer IS-MEMBER-OF rpms/$repo))

Or perhaps it's enough just to be in packager group, not sure if that's too broad though.

  • When do you need this? (YYYY/MM/DD)

the sooner this happens, the fewer valids you need to provide, but there will be a lot more requests coming soon.

  • When is this no longer needed or useful? (YYYY/MM/DD)


  • If we cannot complete your request, what is the impact?

more manual work for releng, and more frustration for flatpak contributors.

Metadata Update from @phsmoura:
- Issue tagged with: medium-gain, medium-trouble, ops

a year ago

Metadata Update from @humaton:
- Issue untagged with: ops
- Issue tagged with: dev

a year ago

So, we discussed this some at this mornings releng meeting.

We aren't against the idea... but we aren't sure about 'flatpak-sig'. Since sig's normally have no rules for who is a sig member.

In this case I suppose we could make a group and the flatpak sig as a body could decide some rules for adding/removing people to that group so we could be assured that they were trustworthy fedora contributors and not someone just joining to add a bad flatpak. ;)

We are in a (kind of) similar situation with the Rust SIG, where we routinely need to create compat packages (which don't require package review). I'm not sure if automating this entirely is a good idea, but if somebody wanted a rule for it, then it would probably look something like this:

  1. strip [0-9], dots (optionally, with one leading underscore) from the right side of the package name in the request (i.e. _0.1, _2, 0.1 or 2)
  2. if rpms/package-name-without-suffix already exists, then request is OK. if that doesn't exist, then not OK, as there is no package with the unversioned "base name"
  3. check if stripped digits and dots from step 1 match any of these patterns: [0-9]+ (i.e. a number without dots), 0\.[0-9]+ (a version like 0.9 or 0.12), or 0\.0\.[0-9]+ (a version like 0.0.10 or 0.0.90). These are the only valid "compat suffix" patterns for Rust packages, if the suffix looks like something else, then it's either packager mistake or an invalid request.

Edited step 1. to also take underscores into account

I floated this in IRC for Rust a while back, glad to see it's not just limited to Rust

I think Fabio's suggested algorithm for Rust would be safe. One caveat is it does not handle some weird corner cases e.g. where the base package ends in a number - rust-sha1 -- the compat package is actually rust-sha1_... e.g. rust-sha1_0.6. So in addition to step 1, if the next character is an underscore and after that you get a valid existing package ending in a digit that's valid too.

Login to comment on this ticket.

Boards 1
Dev Status: Backlog