LINUX.ORG.RU
ФорумTalks

Про зависимости и самодостаточные пакеты


0

0

по мотивам Решил отрезать от основного топика, чтобы обсудить это отдельным вопросом.

Вопрос: почему так много зависимостей и почему нецелесообразно в данной ситуации делать самодостаточные пакеты.

Итак, мало кто понимает, как обстоит ситуация на самом деле. Ест бинарник, чтобы каждый кодер не писал 100500 раз одни и те же функции, которые выполняют какие-то типовые действия, придумали библиотеки, которые являются коллекциями функций, которые каждый кодер может вызвать в своей программе. Это существенно сокращает время разработки и уменьшает размер программы. При этом разные программы могут юзать одну и ту же либу, вызывая ее функции, тем самым сокращать размер потребляемой памяти <-- вот эти характеристики являются первостепенными в событии «появление библиотек»

Вообще теоретически всё очень круто: делаем либу, кодеры вызывают функции и куда не посмотри - всё очень здорово. НО! т.к GNU/Linux не стандартизирован нет офиц библиотек, которые бы покрывали бОльшую часть потребностей кодеров, которые разрабатывают программы. Попытка сделать что-то - это создание toolchain. Смотрим в вики

GNU toolchain — набор созданных в рамках проекта GNU пакетов программ, необходимых для компиляции и генерации выполняемого кода из исходных текстов. Являются стандартным средством разработки программ и ядра ОС Linux.

Но т.к зависимости есть(как свершившийся факт), то делаем вывод о том, что функций библиотек, которые есть в toolchain недостаточно для осуществления разработки программ.

Хорошо, есть сторонние библиотеки. И это нормально. Но проблема в том, что никто не проверяет софт, какие функции юзаются из этих библиотек. Я подозреваю, что 98% всех функций, которые юзаются во всем софте(актуальном) размазаны по всем этим зависимостям. Т.е так: есть функцияХ0 в glibc. Она выполняет то что нужно. Но васян, который кодит, по каким-то причинам использует другую либу, в которой есть функцияХ1, выполняющая то же самое, что функция glibc.функцияX0. Из-за этого мы факт появления зависимости, которой по определению не должно быть. Думаю, что уровень дебилизма там достигает невероятных масштабов и кмк там даже есть такой вариант развития события:

Кодер юзает функцию somelib10.функцияX10, которая зависит от somelib9.функцияX9, которая зависит от somelib8.функцияX8. А в функции somelib8.функцияX8 вызывает функцию glibc.функцияX0. И самое интересное, что функционал функци somelib10.функцияX10, которую вызывал васян равна функционалу функции glibc.функцияX0

Похоже на шутку, не правда ли? Но это, блин, не шутка. В итоге мы имеем несколько зависимостей и одну большую glibc. Хотя, васян мог просто заюзать glibc, которую юзают многие кодеры(прямо - что есть норм или косвенно(но обосновано косвенно).

И поэтому мы получаем такие финты

┌─[debian]─[~] └──╼ apt-get install xfburn Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: xfburn 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 410 kB of archives.

┌─[✗]─[debian]─[~] └──╼ apt-get install brasero Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: aspell aspell-en brasero-cdrkit brasero-common cdrdao dvdauthor enchant genisoimage gnome-user-guide growisofs gstreamer1.0-pulseaudio libbrasero-media3-1 libenchant1c2a libgstreamer-plugins-bad1.0-0 libiptcdata0 libjavascriptcoregtk-4.0-18 libnautilus-extension1a libperl4-corelibs-perl libquvi-0.9-0.9.3 libquvi-scripts-0.9 libtotem-plparser-common libtotem-plparser18 libtracker-sparql-1.0-0 libwebkit2gtk-4.0-37 libyelp0 lua-bitop lua-expat lua-json lua-lpeg lua-socket wodim yelp yelp-xsl Suggested packages: aspell-doc spellutils vcdimager libdvdcss2 tracker readom cdrkit-doc gstreamer1.0-plugins-bad libenchant-voikko libwebkit2gtk-4.0-37-gtk2 The following NEW packages will be installed: aspell aspell-en brasero brasero-cdrkit brasero-common cdrdao dvdauthor enchant genisoimage gnome-user-guide growisofs gstreamer1.0-pulseaudio libbrasero-media3-1 libenchant1c2a libgstreamer-plugins-bad1.0-0 libiptcdata0 libjavascriptcoregtk-4.0-18 libnautilus-extension1a libperl4-corelibs-perl libquvi-0.9-0.9.3 libquvi-scripts-0.9 libtotem-plparser-common libtotem-plparser18 libtracker-sparql-1.0-0 libwebkit2gtk-4.0-37 libyelp0 lua-bitop lua-expat lua-json lua-lpeg lua-socket wodim yelp yelp-xsl 0 upgraded, 34 newly installed, 0 to remove and 1 not upgraded. Need to get 39.7 MB of archives. After this operation, 147 MB of additional disk space will be used. Do you want to continue? [Y/n]

┌─[✗]─[debian]─[~] └──╼ apt-get install k3b Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: aspell aspell-en cdparanoia cdrdao docbook-xml docbook-xsl dvd+rw-tools enchant genisoimage growisofs gstreamer1.0-pulseaudio icoutils k3b-data kate-data katepart kde-runtime kde-runtime-data kdelibs-bin kdelibs5-data kdelibs5-plugins kdoctools libattica0.4 libcanberra-pulse libdbusmenu-qt2 libdlrestrictions1 libenchant1c2a libfam0 libgpgme++2v5 libimobiledevice6 libiodbc2 libk3b6 libk3b6-extracodecs libkactivities6 libkatepartinterfaces4 libkcddb4 libkcmutils4 libkcompactdisc4 libkde3support4 libkdeclarative5 libkdecore5 libkdesu5 libkdeui5 libkdewebkit5 libkdnssd4 libkemoticons4 libkfile4 libkhtml5 libkio5 libkjsapi4 libkjsembed4 libkmediaplayer4 libknewstuff3-4 libknotifyconfig4 libkntlm4 libkparts4 libkpty4 libkrosscore4 libktexteditor4 libkxmlrpcclient4 libmusicbrainz5cc2v5 libnepomuk4 libnepomukquery4a libnepomukutils4 libntrack-qt4-1 libntrack0 libperl4-corelibs-perl libplasma3 libplist3 libpolkit-qt-1-1 libqt4-qt3support libsolid4 libsoprano4 libthreadweaver4 libupower-glib3 libusbmuxd4 libvcdinfo0 ntrack-module-libnl-0 oxygen-icon-theme phonon phonon-backend-gstreamer phonon-backend-gstreamer-common plasma-scriptengine-javascript sgml-data soprano-daemon sound-theme-freedesktop upower usbmuxd vcdimager wodim Suggested packages: aspell-doc spellutils docbook docbook-dsssl docbook-defguide dbtoepub docbook-xsl-doc-html | docbook-xsl-doc-pdf | docbook-xsl-doc-text | docbook-xsl-doc docbook-xsl-saxon fop libsaxon-java libxalan2-java libxslthl-java xalan cdrskin cdrkit-doc libterm-readline-gnu-perl | libterm-readline-perl-perl k3b-extrathemes k3b-i18n normalize-audio movixmaker-2 kde-config-cddb finger libenchant-voikko fam libusbmuxd-tools iodbc hspell media-player-info phonon-backend-vlc phonon4qt5-backend-gstreamer perlsgml w3-recs opensp virtuoso-minimal The following NEW packages will be installed: aspell aspell-en cdparanoia cdrdao docbook-xml docbook-xsl dvd+rw-tools enchant genisoimage growisofs gstreamer1.0-pulseaudio icoutils k3b k3b-data kate-data katepart kde-runtime kde-runtime-data kdelibs-bin kdelibs5-data kdelibs5-plugins kdoctools libattica0.4 libcanberra-pulse libdbusmenu-qt2 libdlrestrictions1 libenchant1c2a libfam0 libgpgme++2v5 libimobiledevice6 libiodbc2 libk3b6 libk3b6-extracodecs libkactivities6 libkatepartinterfaces4 libkcddb4 libkcmutils4 libkcompactdisc4 libkde3support4 libkdeclarative5 libkdecore5 libkdesu5 libkdeui5 libkdewebkit5 libkdnssd4 libkemoticons4 libkfile4 libkhtml5 libkio5 libkjsapi4 libkjsembed4 libkmediaplayer4 libknewstuff3-4 libknotifyconfig4 libkntlm4 libkparts4 libkpty4 libkrosscore4 libktexteditor4 libkxmlrpcclient4 libmusicbrainz5cc2v5 libnepomuk4 libnepomukquery4a libnepomukutils4 libntrack-qt4-1 libntrack0 libperl4-corelibs-perl libplasma3 libplist3 libpolkit-qt-1-1 libqt4-qt3support libsolid4 libsoprano4 libthreadweaver4 libupower-glib3 libusbmuxd4 libvcdinfo0 ntrack-module-libnl-0 oxygen-icon-theme phonon phonon-backend-gstreamer phonon-backend-gstreamer-common plasma-scriptengine-javascript sgml-data soprano-daemon sound-theme-freedesktop upower usbmuxd vcdimager wodim 0 upgraded, 90 newly installed, 0 to remove and 1 not upgraded. Need to get 72.2 MB of archives. After this operation, 182 MB of additional disk space will be used. Do you want to continue? [Y/n]

Пилить самодостаточные пакеты не имеет смысла т.к самодостаточный k3b будет весить 3гб. Почему? Смотрим выше.



Последнее исправление: Xwo (всего исправлений: 1)

Пилить самодостаточные пакеты не имеет смысла т.к самодостаточный k3b будет весить 3гб. Почему? Смотрим выше.

Не будет столько он весить. Сотню мегабайт может будет, но не гигабайты. Проверено на других приложениях.

Quasar ★★★★★
()

Вот есть у меня машина без доступа в интернет куда мне нужно поставить условную софтину, и я бы предпочел выкачать 3 Гб за раз, чем пердолиться с выкачиванием зависимостей и беготней между машиной с интернетом и без интернета.

Да да, сейчас напишут, что это мои проблемы и у белых людей интернет всегда и везде и можно качать терабайты без ограничений.

asaks
()
Ответ на: комментарий от crutch_master

Ну так собственно API библиотек это и делает. Проблема в том, как раз, что кто стандартизировать то АПИ будет?

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

Не нужно ничего стандартизировать. Нужно только описать (на машиночитаемом языке) как и откуда брать данные, что передавать и описание всяких прокси и отношения между типами данных (соответствует/расширяет и т.д)

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Но нынешняя разработка - это не делфи. Приложению, вот, нужна половина qt. Реально нужна. И другому приложению тоже она нужна. Итого у тебя 2 приложения и у которых внутри по почти целому qt. А кому-то нужен целый хром. И таких много. И вот они все тащат этот хром с собой не только на диск, а еще в оперативку. Может быть на самом деле он им и не нужен, то там отрисовка окошка в принципе немыслима без всего движка и её просто невозможно как-то отрезать.

Если приложение пишется новое, то от qt может быть там нужна лишь рисовалка окон, которую можно взять не из qt. qt заменится местными модулями, которые компилятор умеет компилять более умно. Чего не хватит, то влинкуется со стороны. Есть ещё и умная линковка, когда перед сборкой бинарь крошится на кусочки и в итоговый бинарь идут только нужные. А кому нужен хром, те прилинкуют хром - с браузерами жопа, с таким вэбом нет хороших решений.

Napilnik ★★★★★
()
Ответ на: комментарий от system-root

если скомпелять этот твой k3b во что-то вроде снапа — будет примерно 80 мегабайт.

И хрен этот снап потом запустишь кроме как на дистрах специально для этой сборочки предназначенных. Из снапа наружу торчит куча зависимостей, если в линуксе их нет, то жопа.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

ну сделают фигнап, у которого не будет жопы. или там, фигакпак.
меня это вообще меньше всего волнует.
а на счёт зависимостей — нужно просто ближе к 2020 году наконец прийти к «базовой системе» или «базовому образу», где компоненты не на синюю изоленту примотаны, просто потому что. а являются минимумом для запуска других штуковин.

system-root ★★★★★
()
Последнее исправление: system-root (всего исправлений: 1)
Ответ на: комментарий от system-root

Есть флатпак, программы для которого весят много. Флатпак появился недавно и по факту у него самого большие зависимости. Как сборки программ сделанные для сегодняшнего флатпака заработают без переделки на новых флатпаках лет через 10-15 - большой, большой вопрос. Возможно, нерабочие программы просто по тихому уберут из актуальных версий его репозитория.

Napilnik ★★★★★
()
Ответ на: комментарий от system-root

а на счёт зависимостей — нужно просто ближе к 2020 году наконец прийти к «базовой системе» или «базовому образу», где компоненты не на синюю изоленту примотаны, просто потому что. а являются минимумом для запуска других штуковин.

Это я давно предлагал, да только линуксоиды от этой идеи струю кирпичей из одного места метали. Как-же, кто-то укажет всем дистростроителям, какие либы и каких версий должны быть в системе - вот именно эти либы а не самые новые, свежескачанные в гитов. Это же не свободно! А то что есть сейчас, это свобода:)

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

думаю надо не предлагать, а просто говорить об этом, меняя взгляды контингента и вытесняя лобби луддитов со сцены.
всё равно ни ты, ни я, ни кто-то из регистрантов не будет это воплощать в жизнь. это сделаю другие умные (вряд ли) дяди.

и я вижу смысл только в том, чтобы остатки ру комьюнити перестали генерировать токсичное инфополе вокруг нового. вокруг необходимых, неотвратимых изменений.
чтобы можно было открыть лор и обсуждать, а не троллировать ненужников-поклонников РМС.

system-root ★★★★★
()
Ответ на: комментарий от system-root

Да всё бред, даже устоявшееся положение, которое пока что всех устраивает.

Сравни старые коммерческие юниксы и современный репозитарный линукс.
разница в пользу линукса.

Deleted
()
Ответ на: комментарий от system-root

я их видел по картинкам с 1997 и впервые пущупал в 2005, когда солярис 10 откуинулся в народ.

Deleted
()
Ответ на: комментарий от system-root

Идёшь к Бачило на канал и смотришь на его упражнения с Солярис10, понимаешь что это не про десктоп и пользователей совсем от слова совсем.

Deleted
()
Ответ на: комментарий от Deleted

не обязательно «для пользователей» должно быть десктопным.
это просто значит, что можешь что-то сделать без приглашения интегратора.
у меня год крутился OmniOS, пока не допилили ZoL и ничего страшного. там с открытой соляркой такой треш сейчас творят, что назвать это «старым юниксом» невозможно. кубернетисы в контейнерном соку обмазанные нодой, и прочий ад.

system-root ★★★★★
()
Ответ на: комментарий от system-root

Огорчу тебя, они и по сей день есть...

Jetty ★★★★★
()
Ответ на: комментарий от Jetty

Что-то там «open» - это уже не поделка только MS, хотя в любом случае он мало кому нужен.

crutch_master ★★★★★
()
Ответ на: комментарий от Deleted

LSB?

Вот именно что "?". Ни ты ни я не станем собирать по этому талмуду дистр и тестировать «а что это такое». Набор стандартных либ стандартных версий должен быть в каждом дистре претендующем на название десктопного. Назвался десктопом - установи у себя сервиспак десктопных либ, чтобы любая сторонняя программа, не из репозитория, могла их использовать. Вот что нужно - сервиспаки десктопных либ, которые менются на чаще раз в 5 лет, и в системе их может быть несколько версий. В винде хорошо придумано, если прога не работает, её можно запустить в режиме совместимости с винХРю сп3,2,1, а в линуксе никаких сп нету, зато есть анархия и произвол руководства из секретного кабинета.

Napilnik ★★★★★
()
Ответ на: комментарий от Jetty

Бадааааам, ты изобрел биндинги ) И да они существуют.

Си и производные предлагают дерьмовую систему заимствований из системы и либ. Паскаледельфийские модули импорта предоставляют программисту возможность не черпать ложкой в борщ из общего унитаза, как это принято в Си и производных. Когда компилируешь программу на паскаде/дельфи тебе системные заголовки не нужны совсем, всё что нужно перенесено из них в модули импорта заблаговременно, и только если чего-то не хватает, ты можешь слазить в заголовки и перенести из них в модуль то, что сочтёшь нужным.

Napilnik ★★★★★
()
Ответ на: комментарий от crutch_master

Как раз способы обмена и стандартизируют.

cvs-255 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.