On Wed, 2017-08-30 at 11:04 -0500, Jimmy Berry wrote:
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.
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 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.
You overestimate what the rings are good for I think
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.
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 config 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 about.
But all in all happy we agree on the general way forward PS: how comes this list has an invalid post header? List-Post: <mailto:opensuse-releaseteamopensuse.org> whenever I hit reply to list, I get an invalid email address filled in my client.