On Wednesday, August 30, 2017 10:30:39 AM CDT Dominique Leuenberger / DimStar wrote:
I don't think every package in a ring has to be installable inside the ring.
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 about. -- Jimmy -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org