openSUSE / openSUSE-release-process

Other
8 stars 9 forks source link

[15.3 retro] overlap package between SLE and Backports #71

Open nilxam opened 3 years ago

nilxam commented 3 years ago

We have a list of overlap package between SLE and Backports, the reason is the package in SLE was shipped by specific architecture, eg. packages in WE extension(x86_64 only) like alsa-oss. We do rebuild the package in Backports for other architectures and was providing via PackageHub.

Damage The request delegating don't know it is a SLE origin, therefore won't have a chance to do a submission mirroring

lkocman commented 3 years ago

Max can we kill all forks and move them to backports subpackages module/product?

lkocman commented 3 years ago

Wolfgang: this should be possible

lkocman commented 3 years ago

Let's track this task on the Release Team meeting minutes

lkocman commented 2 years ago

Any progress Wolfgang?

deneb-alpha commented 2 years ago

Given that we are shipping only part of those binaries in SLE (only some architectures), I think it's easier to handle those packages via SLE-Module-Packagehub-Subpackages (the SLE side of PackageHub) making sure we are shipping there what is needed (and checking better also for issues).

We can deliver to WE the x86_64 binaries and all the rest via SLE-Module-Packagehub-Subpackages.

lkocman commented 2 years ago

@deneb-alpha agreed, it seems that any other implementation would not be possible. Could we agree on having this with RC timeframe? I believe Beta is too close to have it done.

deneb-alpha commented 2 years ago

@deneb-alpha agreed, it seems that any other implementation would not be possible. Could we agree on having this with RC timeframe? I believe Beta is too close to have it done.

I saw we have a call scheduled for this week. :)

The required time depends from the amount of packages we need to deliver. In general, we need to have a maintenance incident that includes the source package and with that we can also make the changes to the channels.

This will also require some QA time for testing the incidents and from maintenance side also some validation for being sure that we are not introducing conflicts. long story short, we need to plan a bit and coordinate but in general I don't think it's not doable for RC.

I'm not sure if those changes will require some adjustments on the PackageHub side but this is something we can clarify in our call.

lkocman commented 2 years ago

Just an update on the issue, maintenance team is releasing updates to affected packages (Packages from Workstation Extension module shipped only on x86_64) to the Packagehub channel list is updated weekly see e.g. https://etherpad.opensuse.org/p/ReleaseEngineering-20220427#L154 the last update

nilxam commented 2 years ago

Another update: not just for WE, for non-WE also, the duplicated package has been deleted from Backports. Some exception is several particular multibuild pacakge, and packages from SLEFork subproject.