On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert:
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.
I do see the benefit this will bring for some folks but hope to limit the consequences for others.
Are some numbers available how often Leap to SLE switches happen compared to the number of all Leap user installs? And perhaps how often complains are raised because of the need to reinstall packages?
Please let me exaggerate a little bit: Are we trading saving bandwidth for those wanting to switch at the price of requiring all Leap users to add and trust a signing key of an entity that might follow rules not controlled by openSUSE?
I don't want to argue against having SUSE signed binaries in the openSUSE repositories but would really prefer if a technical solution can be found, where this is not the only signature.
With such multi-signed packages Leap users can solely rely on the openSUSE signature, while those switching to SLE (what has to include adding trust to the SUSE key) have SUSE signatures already available for shared packages without need to reinstall.
We can just resign packages without rebuilding them. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org