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 10:21 -0500, Jimmy Berry wrote:
It appears that in order to workaround the intermittent false-
negatives
emitted by repo_checker a number of patterns have been whitelisted.
As an
aside, during my requests for feedback about issues and manual
accepts for
previous repo_checker nothing was really mentioned although we have
since come
across several cases that would have been present previously as well.
As in
this case of working around an issue it would be preferred if a
discussion is
started rather than me having to stumble across such workarounds.

Currently whitelisted patterns:

patterns-base-apparmor
patterns-kde-kde_telepathy
patterns-media-rest_cd_gnome
patterns-media-rest_cd_kde
patterns-media-rest_dvd

Most can probably disappear already again - as they were temporarily
needed (as an alternative to rebase a whole staging).

Maybe we can have this kind of 'staging based, temporary ignores' as
part of the project meta data the checker would take into account?
Would be better than having a whitelist which I will keep forgetting to
clean up.


This is certainly less than ideal as it means that any real problems
will be
ignored. In fact one of the oldest issues in against the repo_checker
is in
regards to packages reference by patterns being removed without any
proper
warning [1].

I tried to only add stuff which I understood when I saw them in staging
(pattern-kde for example got updated, telepathy dropped, which meant
the stuff in the existing stagings were no longer happy)

repo_checker acts like an extension of OBS in that OBS would check
that the
BuildRequires can all be met before attempting to build while
repo_checker
ensures the Requires can be met. Currently, anything added to the
rings must
have all of the build dependencies present. This has led to packages
being
split and all sort of fun stuff to avoid bringing in too many
dependencies. At
the end of the day, packages in rings are only passed because all
their
dependencies are also available in the rings.

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.

Contrast that to patterns which while having their minimal build
dependencies
present do not have there install-time dependencies present. That
combined
with the exact version Requires causes the repo_checker to correctly
find that
they are not installable from the letter staging. Not having the
install-time
requirements met within the staging seems like a short-cut rather
than an
idealistically correct setup. If patterns are of enough importance to
be in
the rings, their install-time requirements ought to be as well.
Otherwise, it
would seem logical to remove them from the rings since they really
are not
being checked as the primary purpose of a pattern is to pull in other
packages
which cannot be confirmed.

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.

Alternatively, not having the hard version requirements would remove
the
repo_checker errors, but still fail if packages required by the
pattern are
removed. Either way, from what I can tell this should really be a
process
change rather than either special-casing in repo_checker or
whitelisting to
hide the problem.

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.

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 ?

Cheers,
Dominique
< Previous Next >
List Navigation
Follow Ups
References