Чому в офіційних сховищах так важко знайти оновлене програмне забезпечення для кінцевих користувачів? [зачинено]

Ні, це не копія /ubuntu/151283/why-dont-the-ubuntu-repositories-have-the-latest-versions-of-software.

Моє питання тут стосується лише програмного забезпечення для кінцевих користувачів. Я цілком розумію аргумент стабільності щодо недорогих пакетів та інших матеріалів, але чому кожні кілька днів є багато пакетів для оновлення, але жоден із них не стосується моїх загальних програм?

Це призводить нас до абсурду, що багато розробників пропонують нам просто не використовувати офіційні сховища, оскільки вони застаріли. Зі своїх кушеток уявіть собі мобільний світ, куди вам доведеться завантажувати ваші APK / IPA з усіх куточків Інтернету, оскільки Google Play / App Store включає лише версію, що досягла року.

Ось що відбувається на Ubuntu. Магія створення простого у використанні способу встановлення програмного забезпечення повністю накручена, оскільки матеріал занадто старий.

Приклад: Щойно я отримав Ubuntu 16.04 на своєму комп’ютері, а версія Caliber майже 5 місяців - 2,55 знаходиться в репо, тоді як 2,66 вже вийшов.

Якщо оригінальні розробники не піклуються про підтримку PPA, нам залишаються старі шкільні дні, коли ми відвідуємо сайти для завантаження, отримуємо тарболи або деби та вручну встановлюємо речі. Ubuntu раніше був класним, але тепер у цьому аспекті старший за Windows.

Чи єдиний відгук тут? Обслуговувачам Ubuntu є ще багато чого, ніж бути в курсі всіх версій програмного забезпечення між версіями Ubuntu ? Чому розробникам програмного забезпечення не простіше / можливо оновити власне програмне забезпечення у сховищах Ubuntu?

Чому розробникам програмного забезпечення не простіше / можливо оновити власне програмне забезпечення у сховищах Ubuntu?

Розробники програмного забезпечення регулярно оновлюють своє програмне забезпечення. Тому ви знайшли нову версію Caliber. Однак вони не надсилають безпосередньо свої оновлення до сховища Ubuntu. Причини вже наведені у відповідях, які ви пов’язали зі своїм питанням.

Вони також не завжди можуть забезпечити ППД, оскільки це додасть їм додаткового навантаження. Потім їм потрібно буде надати пакети для декількох дистрибутивів. І не забувайте, що в кожному дистрибутиві є кілька не-EOL-версій! Якщо вони хочуть надати пакет для Ubuntu, їм потрібно буде створити його для 16.04, 14.04 та, ймовірно, 12.04. Тоді користувачі Fedora, Debian, Arch починають скаржитися! Це непросто! Ось чому PPA зазвичай надаються сторонніми обслуговуючими особами.

Однак існує й інший альтернативний підхід для надання останніх програмних програм для кінцевих споживачів, що розробляються в наші дні. Це упаковка кожного компонента програми в один файл. Вони працюють в основному в ізольованому середовищі, як у контейнері, і не потрібно сумісні з поточними бібліотеками, встановленими в системі. Наприклад, ви можете запустити gtk-3.20 додаток у Xenial, який в основному постачається з 3.18 компонентами.

Але вони теж мають свої проблеми! (Див. Виноски)

Деякі з підходів:

• AppImages
• FlatPak від Gnome
• Знімок від Ubuntu

Обслуговувачам Ubuntu є ще багато чого, ніж бути в курсі всіх версій програмного забезпечення між версіями Ubuntu?

Обслуговувачі Ubuntu намагаються досягти важливих етапів кожного випуску. Щоб Ubuntu залишався стабільним, їм потрібно переконатися, що кожен пакет працює так, як очікувалося. Наприклад, нещодавно тут було задано питання про отримання останнього KDEConnect 1.0 в Ubuntu 16.04. Але виявлено, що kdeconnect1.0 вимагає Qt 5.6. Щоб надати їм Qt 5.6, вони повинні переконатися, що інші пакети в офіційному сховищі добре справляються з ним. Це означає, що перестроювання, повторне тестування всіх KDE-пакетів - це справді величезне завдання.

Якщо вам потрібні новітні програмні засоби, ви можете спробувати скористатися провідними дистрибутивами або іншим підходом до єдиного пакету, згаданим раніше у питанні.

Деякі проблеми з упаковкою одного файлу:

1. Зазвичай вони мають більший розмір (адже вони пакують все необхідне)

2. Встановлення їх зробить вашу систему більшою, оскільки у вашій системі буде кілька копій одних і тих же бібліотек, які використовуються кожним пакетом.

3. Цей формат упаковки вимагає від технічного обслуговування пакунків перевірити інтеграцію з самими бібліотеками. Це додаткове навантаження на них. З apt, yumпідхід, вони турбували тільки з ядром-додатки. Вони могли просто припустити, що в дистрибутиві доступний lib-gtk-xy-1.5.

4. Знову ж таки, з тих же міркувань, обслуговуючі пакети тепер будуть турбувати звіти про помилки, пов’язані з бібліотеками, що входять до їх пакету. У традиційному підході це було завданням технічного обслуговування цього конкретного пакету lib.