Mailinglist Archive: opensuse-releaseteam (19 mails)

< Previous Next >
Re: [opensuse-releaseteam] Proposal to resolve the root cause behind whitelisting of Factory patterns for repo_checker
On Wed, 2017-08-30 at 11:04 -0500, Jimmy Berry wrote:
On Wednesday, August 30, 2017 10:30:39 AM CDT Dominique Leuenberger /
I don't think every package in a ring has to be installable inside

I can easily create a source package in ring0 that produces a FOO-
package that has a Requires: texlive - yet, I certainly do not EVER
want texlive in ring0. And as long as FOO has no build deps on
there is no need to do so.

I do not disagree that packages inside of rings are not always
within the ring (hence the root of pattern issue). In fact that was
my primary
point, that they should be treated just like build requirements.
Otherwise, we
may end up shipping a ring package that is not installeable which
seems to
void the main idea behind having it in a ring.

The rings are not shipped (separately) - they are not 'visible' in the
product but are there for 'us' to have some basic bootstrap packages
and the minimal set of what we want to safeguard to not break against
each other (what needs to be fixed as a minimum before a gcc update or
glibc update can get in for example)

We care for SOME patterns - and the not for others.. the ones we
for are referenced by the testdvd creation script - and the kiwi
gets invalidated if the pattern is not installable.

Sure, but for those we do not care about it begs if they should be in

You overestimate what the rings are good for I think

Hence back to the proposal: can we have the repo_checker exception
a staging project as part of the staging project directly instead
of a
global config ?

This seems like a good suggestion in that is also mirrors the
proposal for a
ring command and the workflow in general. If the problems could be
avoiding on
a more general level that would certainly seem better to me, but if
no desire
to make changes to achieve that goal this would seem the next best.

right - could be someting like 'osc staging repocheckignore binary' or
whatever - I don't mind much how the interface to it will be.

The plan for the ring command and all other such staging information
is stored
in psuedometa (project description yaml). Alternatively, the remote
could be extended to support per staging project overrides, but
woudh need a
place to put it (ie a package) unless somehow morphed into
psuedometa. Not
sure if this would applicable to other commands/variables. Something
to thing

But all in all happy we agree on the general way forward

how comes this list has an invalid post header?
List-Post: <>

whenever I hit reply to list, I get an invalid email address filled in
my client.
< Previous Next >
List Navigation