от Balkantel(20-04-2020)

SUSE Linux Enterprise и openSUSE бинарно съвместими ?

В новинарския сайт на openSUSE се появи съобщение за предложение от SUSE Enterprise, относно бинарно обединяване на двете дистрибуции.

https://news.opensuse.org/2020/04/10/SU...

Предложението е оформено като FAQ документ, наречен "ClosingTheLeapGap" и се
чете тук: https://en.opensuse.org/Portal:Leap/FAQ...

Води се и дискусия с общността как евентуално може да се случи това.
https://lists.opensuse.org/opensuse-pro...

openSUSE вече споделя голямо количество сорс код със SLE. Сорс кодът на около 4000 пакета идва директно от SLE, а други 8000 се поддържат от общността.
Това от една страна е довело до голямо облекчаване в openSUSE, премахвайки двойната работа върху 4000 пакета. А от друга, дългогодишни разработчици на openSUSE са се сблъсквали с така наречения "корпоративен товарен влак" https://en.opensuse.org/openSUSE:Freigh...,
който им пречи свободно да допринасят в развитието на openSUSE. Дори промени в
незначителни пакети, като `mercurial`, са били отказвани по причини, цитирам:

> We did not receive any business reasoning for the request

От водените разговори до момента става ясно, че и двете страни виждат облаги
от обединението, но също така и трудности. За SUSE Enterprise са важни сертификацията
за сигурност и NDA споразуменията им с трети страни, които изискват компилациите
да стават в контролирана от тях среда. За общността openSUSE е важен отворения процес
на разработка т.е всеки да допринася без сблъсък с "товарния влак".
В същото време, трябва да се гарантира  доверие на потребителите, без черни кутии
в предоставените пакети, което, от своя страна, изисква разработка и компилации
в отворена среда OBS: https://openbuildservice.org/

Как тогава ще се случат нещата? За бинарната съвместимост пакетите трябва да
идват от едно и също място.

За да гарантират отворена разработка, SUSE Enterprise предлага модернизирани
инструменти и отваряне на част от JIRA платформата си.
По-точно, говорят за предоставяне на възможности като проследяване на
*FeatureRequests* и *fast-track code-contributions*, възможност за коментари,
размяна на пачове и така нататък.

> SLE would like to treat openSUSE as a partner here. Process should be
> simple enough and offer fast-track for code-contributions.
>
> Where contributors would be able to see request updates, be able to
> comment, exchange patches and so on.
>
> SUSE has new tools in place, and I'd like to see them being used, and
> get external requests structure, expected visibility during evaluation.

Приемане на openSUSE:Factory_development_model с времето също е възможно
https://en.opensuse.org/Portal:Leap/SLE..., за да бъде увеличена
пропускливостта и прозрачността в разработката на SLE и Leap.

Това, което предлага openSUSE общността върху предложението на SUSE Enterprise e
двойно подписване на пакетите идващи от SLE, за да гарантират доверието на
потребителите си. Идеята е всички пакети да бъдат компилирани също и в отворената
среда OBS. Ако резултатът от двете компилации е идентичен, бинарният пакет на SLE
ще бъде допълнително подписан с ключа на openSUSE и включен в хранилищата.
Ако резултатът е различен, в хранилищата ще бъде включен пакета компилиран от
OBS и единствено подписан с ключа на openSUSE. Общността се надява с времето
единично подписаните пакети да намаляват.

От SUSE Enterprise приемат идеята за двойно компилиране и сравнение върху OBS,
понеже изчислителната мощност не е проблем. Според тях, няма да има
пропаднали сравнения на пакети  и е излишно управлението на две
хранилища. Двойното подписване също им изглежда ненужно усложнение, което освен
това все още не се поддържа от RPM.

Те предлагат потребителите да използват два ключа в паралел. Това решение
обаче, няма как да гарантира 100% доверието, понеже общността няма контрол
върху това какво друго SUSE Enterprise подписват с техния ключ.

Тази година ще видим две версии на openSUSE. Версията, която очакваме през юни
(Leap 15.2) и една неочаквана – през октомври (Jump 15.2). Leap 15.2 е стандартната
openSUSE, направена по текущия модел на разработка. А Jump 15.2 ще съществува
няколко месеца и целта и е да бъде изпробван новия модел на разработка с бинарни
пакети от SLE.

Още не е ясно дали двата инженерни отбора ще се съберат успешно. Ясно е, че
SUSE Enterprise трябва да даде повече в това начинание. Те се захващат с нещо,
в което много други са се проваляли преди тях. openSUSE e "OPEN" и вече са дали
всичко от себе си. Те просто искат да са свободни. Може да мислим, че SUSE Enterprise
са готови за това, иначе защо биха правили това предложение изобщо? Варианта за
FreeSLE е обмислян, но не е приет, защото така биха станали конкуренция на openSuse,
а целта им е точно обратната.

Ако двата отбора се сработят, и Leap 15.3, и SLE 15.3 ще бъдат напълно бинарно
съвместими. Това означава безпроблемен преход от Leap към SLE и от SLE към Leap.
Пакетите, произведени от трети страни, за която и да е от двете дистрибуции,
също ще бъдат съвместими.

Ефектът от това начинание ще бъде много по-осезаем от други подобни
взаимоотношения (RedHat/CenOS, Ubuntu/Mint). Потребителите на openSuse
ще имат възможността да използват агресивно тестван и сертифициран софтуер, а
потребителите на SLE, все по-често ще използват "cutting-edge" технологии,
благодарение на масивната подкрепа от огромното openSuse общество.

Чувстват ли се двата екипа достатъчно пораснали, за да намерят решение на
задаващите се проблеми като големи хора? Предстои да разберем.


<< Ubuntu 20.04 LTS | Излезе LXC 4.0 LTS >>