On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote:
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different.
And this is a very important consideration from a support perspective. One part of this is that a user can switch from openSUSE to SLES without having to re-install/switch a bunch of packages. Example: If a user sets up a server using openSUSE Leap and uses only packages that are in the overlapping set between Leap and SLES that user can have a business action only switch from Leap to SLES. Since the packages are already signed by the SUSE key everything in the support system just works once the user is enabled on the business end. That doesn't work for all cases of course. When a user has a system that use KDE and wants support then the user cannot get support for KDE as SLES + Workstation Extension or SLED support GNOME. However, since KDE is in PackageHub the user can still get support for all the packages signed by the SUSE key. Hope this helps in illustrating the advantages for the user w.r.t. using one signing key vs. the other. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo