noarch packages not published properly when previously built arch is disabled

[jberry-suse]

Issue Description

Encountered with openSUSE:Tools/openSUSE-release-tools. Was tired of waiting for s390x to build (extremely slow worker) since it is utterly unnecessary so I disabled it. This resulted in publishing the updated noarch packages to tree, but not repo-md.

From ...primary.xml:

<package type="rpm">
  <name>openSUSE-release-tools</name>
  <arch>noarch</arch>
  <version epoch="0" ver="20180510.846b2bd" rel="349.1"/>

From http tree:

• openSUSE-release-tools-20180510.846b2bd-349.1.noarch.rpm
• openSUSE-release-tools-20180510.b4943dc-351.1.noarch.rpm

b4943dc being newer and desired, but never gets published as publishing shows complete.

Expected Result

The b4943dc binary would be published in repo-md at the least.

How to Reproduce

1. build noarch package for multiple archs
2. disable one of arch (may be dependent on ordering OBS uses internally)
3. observe new package version not published in repo-md

Further Information

This is likely extremely related to #4373 which likely indicates the approach used in implementation as questionable. I am adding ExclusiveArch: x86_64 since that will likely solve for same reasons as other issue. If this is not to be fixed I would suggest removal of disabled feature being a topic of consideration.

[adrianschroeter]

publishing happens when a repo/arch is finished, so s390 should not slow you down.

You will have then all versions of the package in the repo.

[jberry-suse]

I posted observed evidence showing a different behavior. What you described would be nice, but given noarch are shared it seems to along with the behavior I documented.

[adrianschroeter]

sorry, but I don't see any evidence atm.

It would be a createrepo_c bug if both binaries are there, but metadata would contain only on package. but I am not able to reproduce it that with the version of createrepo_c on the backend servers.

Please reconstruct the problem, atm it is not there.

[bgeuken]

Just an uninformed guess... could it be that the 20180510.b4943dc-351.1 version was considered to be older and thus ignored by createrepo / the publisher?

[adrianschroeter]

On Dienstag, 15. Mai 2018, 09:19:28 CEST wrote Björn Geuken:

Just an uninformed guess... could it be that the 20180510.b4943dc-351.1 version was considered to be older and thus ignored by createrepo / the publisher?

no, it always adds all files.

…

-- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

[jberry-suse]

I think it had something to do with disabling while existing build job, but I cannot re-create in home project as I see it adding all binaries. Similar to the other issue this is still undesirable since it is adding binaries from the disabled arch. So I have the updated version from the new arch and the stale binaries from the disabled arch. Unlike the other issue I can use:

$ osc wipebinaries -a i586 home:jberry:issue-4968-disabled-noarch openSUSE-release-tools

to drop the stale binaries from the disabled arch and they are removed from repo-md.

As such seems like the only desired outcome would be to automatically wipe binaries when disabled.

[adrianschroeter]

No, this would be a massive incompatible change and it would block other use cases where you just temporary freeze the builds. Also breaking deps when rpms require exact release numbers of noarch packages.

What should happen is:

• you get multiple noarch rpms in repos, if repos got published (per architecture) and one arch has a different version/release number (eg. because architecture specific failures or disabled)
• you get only one noarch if all archs built the same (usual case when all succeed, even when cycles are different).

If you look for a solution to not build or publish binaries then there are ways to switch them to excluded or to apply publishfilter. But this is IMHO out of scope of this bugreport.