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
  • From: Jimmy Berry <jberry@xxxxxxxx>
  • Date: Wed, 30 Aug 2017 11:04:51 -0500
  • Message-id: <5136549.CEHCOF05b7@boomba.local>
On Wednesday, August 30, 2017 10:30:39 AM CDT Dominique Leuenberger / DimStar
I don't think every package in a ring has to be installable inside the

I can easily create a source package in ring0 that produces a FOO-doc
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 texlive,
there is no need to do so.

I do not disagree that packages inside of rings are not always installable
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.

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

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

Most of the issues I'd seen around patterns in stagings is that things
change in oS:F - and if the patterns are the only thing holding off
repo-checker from passing it, I'm certainly not willing to rebase a
staging and have it build a couple hours again.

Not having to rebase for such a case is definitely better and I was not
suggesting that it was not a good idea. Rather avoiding having to tweak the
whitelist would seem preferable if possible.

Hence back to the proposal: can we have the repo_checker exception for
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.

The plan for the ring command and all other such staging information is stored
in psuedometa (project description yaml). Alternatively, the remote config
could be extended to support per staging project overrides, but would 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


To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-releaseteam+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation