koji-shadow strategy

Karsten Hopp karsten at redhat.com
Mon Jan 3 15:28:45 UTC 2011


  Am 03.01.2011 15:46, schrieb Dan Horák:
> here are few of my thoughts before starting koji-shadow
> - need to ask dgilmore for the package list that are expected to be
> missing on ppc/ppc64 (ExcludeArch/ExclusiveArch), he has a script for
> that
> - because the difference between primary and ppc is so large and there
> were mass rebuilds of all python (for 2.7) and perl (for 5.12) packages,
> we shouldn't use the "import-noarch" feature, too new packages would be
> available in the buildroots causing broken dependencies (the
> "prefer-new" feature is needed to include fixed builds)
> - the injected packages, that do not exist in primary koji, should have
> <your_initials>.X suffix in the Release field, so they are later easily
> identified
> - should we really start koji-shadow against dist-f15 or should we start
> with dist-f14 first even without an intention to be complete, just to
> shorten the gap before starting dist-f15
>
> Additions, opinions?
>
>
> Dan

python and perl will be a big mess anyway, I think we should update 
them, import the noarch packages afterwards and fix what whatever we 
broke by doing it that way.

+100 to the suggestion that package with some patches that don't exist 
in primary koji should have your initials in the release field.
  We've done that on s390x and it helped a lot to keep track of those 
packages until the patches got into the packages on the primary archs.

I'd rather concentrate on F15 than filling the web-interface with F14 
failures. For some packages it might be worth building the F14 package 
requirements, but that should be done depending on the problem, not for 
all packages.


    Karsten




More information about the ppc mailing list