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

Она выполняет то что нужно. Но васян, который кодит, по каким-то причинам использует другую либу, в которой есть функцияХ1, выполняющая то же самое, что функция glibc.функцияX0.

такой фигней Qt кстати страдает. Но в общем-то терпимо, ибо набор либ-то стаднартный.

А смысл в самодостаточном k3b? Нужен самодостаточный KDE, ставящийся в /opt. И все будет хорошо: кдешники получат своего монстра и смогут его обновлять хоть каждый день, система останется стабильной и не будет засрана тыщами ненужно-пакетов.

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

ты неправильно понял цитату из вики

тулчейн никаким образом к библиотекам не относится

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

Предлагаю юниксвей, на каждую функцию своя либа

Пока все страдают жуйнёй, Delphi тем временем делает самодостаточный исполняемый файл, который вырезает одну-две функции необходимые для отрисовки окна например, а не тянет за собой QtGui, размером 25МБ. Имея все исходники, размер k3b, при таком подходе был бы 7МБ максимум....

поздравляю, ты изобрел АТЛ, ком+ и системд... проверяли, не взлетает такой подход...

Need to get 72.2 MB of archives
k3b будет весить 3гб

ой всё.

Использую модульный дистрибутив. Модули условно подразделяем на базовые и дополнительные, предполагается что базовые есть постоянно в системе.

Когда модуль делаешь, добавляются только библиотеки которых нет в базовых модулях а также можно прописать зависимость от других дополнительных модулей. В случае если в базовых модулях более старая версия библиотеки, решается вопрос по обновлению базового модуля, либо можно использовать LD_LIBRARY_PATH= и ложить библиотеки в отдельно от общесистемных.

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

В базовых модулях библиотеки libc, xorg и xcb*, libz. Т.e. Самое основное. Остальное в дополнительных.

Если использовать LD_LIBRARY_PATH=, то другие программы эти библиотеки не увидят.

Поставь чистую систему и выполни apt-get install k3b и посмотришь сколько реально зависимостей вытянет. Сейчас-то да, когда 15 гб всех пакетов стоит, осталось вытянуть 72мб

Поставь чистую систему

ubuntu-minimal из https://cloud-images.ubuntu.com/minimal/releases/

~# apt install k3b --no-install-recommends
Need to get 90.2 MB of archives

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

Пока все страдают жуйнёй, Delphi тем временем делает самодостаточный исполняемый файл, который вырезает одну-две функции необходимые для отрисовки окна например

Если пройтись по цепочки зависимостей (либы тоже могут дёргать функционал друг друга) то он всё равно станет непомерно жирным. Плюс ты можешь не знать, что действительно нужно, пока не запустишь свой код.

Если пройтись по цепочки зависимостей (либы тоже могут дёргать функционал друг друга) то он всё равно станет непомерно жирным. Плюс ты можешь не знать, что действительно нужно, пока не запустишь свой код.

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

procedure Button1Click(Sender: TObject);
begin
  {"Чистим" адрес функции от "грязи"}
  @GetSimpleText := nil;
  {Пытаемся загрузить библиотеку}
  LibHandle := LoadLibrary('MYDLL.DLL');
  {Если все OK}
  if LibHandle >= 32 then begin
    {...то пытаемся получить адрес функции в библиотеке}
    @GetSimpleText := GetProcAddress(LibHandle,'GetSimpleText');
    {Если и здесь все OK}
    if @GetSimpleText <> nil then
      {...то вызываем эту функцию и показываем результат}
      ShowMessage(StrPas(GetSimpleText(True)));
  end;
  {И не забываем освободить память и выгрузить DLL}
  FreeLibrary(LibHandle);
end;

А если подходящего сигнала нет?

--strip-all

--strip-all

Это опции компилятора или strip?

Это опция strip, но так же может быть передана линкеру, в том числе через компилятор.

Пишешь его или пишешь прокси. Надо только заморочиться с неймспейсом, чтобы там было что-то типа pupkin.dialogform с кучкой параметром, который потом можно сделать совместимым с любым вменяемым dialogform через тесты гр.Пупкина или еще какие-нибудь костыли.

Ну это тот же жир, только в профиль. Да и у либ есть свои зависимости тоже. Этот GetSimpleText может тянуть за собой почти всю либу. Ну будет у тебя зависимостей не 3гб, а 1.5. Если для каждой поделки надо всё это выкачивать, проблема останется.

Ну будет у тебя зависимостей не 3гб, а 1.5

Не будет. Я когда игрался с Delphi, то там есть такое понятие как пакеты BPL. Так вот, что если есть пару окошек у программы, то она весит 300КБ, а если использовать пакеты, то программа становится 45КБ, но при этом с собой нужно носить 2-е либы по 1-2 МБ, что увеличивало размер и я это не использовал.
То есть, когда вырезаются отдельные функции в исполняемый файл, то он работает на всех компах, где нету этих пакетов BPL. Так что давно есть способы условно нормальной переносимости, так же и там из всей либы используются пару функций.

А если мне в нескольких программах надо? Писать библиотеку с таким функционалом?

окей, не 3гб, а ВСЕГО-ЛИШЬ 495. Не много ли для писалки, не? Вопрос не о snap с squashfs, вопрос о бинарниках, которые должны весить в 20 меньше, чем они весят сейчас. Хотя, даже 24mb - дофига для обычной писалки. Вот 2.4мб - самое то

Как раз тем, что для писалки надо 495мб зависимостей, я и указываю на проблему.

Не будет. Я когда игрался с Delphi

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

не тупи. минус 495 диска ты получишь при использовании apt.
если скомпелять этот твой k3b во что-то вроде снапа — будет примерно 80 мегабайт.
то, что это дерьмо тянет за собой vlc, кодеки и даже protobuf — вопрос к погромистам.

ага. и писать будешь прям из консоли?

к чему этот вопрос? какой ещё консоли?

тебе еще раз говорят, какое отношение имеет снап ко всему этому и какое отношение имеет сжатый squashfs?

Вот возьмём, простое окно для ввода. Есть твой SR_team.inputDialog, который передаёт, например, геометрию окна, надписи (заголовок, подпись поля ввода, дефотлное значение, подписи для кнопок ok/cancel) и получает строку. Есть какой-то qt.inputDialog, который делает тоже самое, плюс еще может картинки приделывать на фон или на кнопки. Ты можешь написать в своём интерфейсе, что SR_team.inputDialog совместим с qt.inputDialogQTCool и на этом успокоиться. Но, если где-то есть gtk.inputDialogGTKVeryCool, который делает тоже самое, что qt.inputDialog, но у него другие названия полей. Из этого мы можем сделать прокси common.GUIInputDialog, в который прописывается весь этот зоопарк диалогов и можно вызывать любые, хоть твой (если решишь сделать себе либу), хоть qtшный, хоть гткшный, хоть велосипед Васяна.
И дело не в том, что у тебя не будет ада зависимостей. Они будут, но их можно будет упорядочить. Если говорить не о периферии, то можно приделать еще кучу тестов типа common.pregexp.test и если васянам нужны pregexp, то они просто пишут что они хотят видеть от него, система прогоняет их вход/выход через тесты и они спокойно ставят common.pregexp в зависимость, которую пользовательская система разрешает хоть перлом, хоть нодой, хоть чёртовой матерью.

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

есмотря на это, отношение имеет такое, что apt не позволяет тебе засунуть все зависимости в контейнер и пожать его.

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

и это реальность прямо сейчас. она не сходится с текстом из твоего поста чуть менее чем совсем никак.

Решение проблем - это решения, которые приводят к изменению реальности.

kdelibs-bin

Подожди ещё пару-тройку лет, пока в стабильный дебиан не завезут k3b на kf5.

где в этом треде я что-то предлагал? наверное там же, где k3b весит 3 гигабайта.

не тут, нет?

несмотря на это, отношение имеет такое, что apt не позволяет тебе засунуть все зависимости в контейнер и пожать его

PS: да ты, я смотрю, приколист.

ну попробуй запустить k3b из консоли, окее

из какой консоли? чё ты пристал ко мне с какой-то консолью, а? нехочу я вообще запускать этот ваш k3b.

Да ну, вы описали все те же библиотеки но с иным типом линковки

посмотри значение слова предлагать в словаре.

ubuntu-minimal из https://cloud-images.ubuntu.com/minimal/releases/

~# apt install k3b --no-install-recommends
Need to get 90.2 MB of archives

вот этой самой консоли с образа минимал. она не содержит иксов. тебе их всякио придётся ставить для к3б

ну во-первых не «всяко». оно уже тянет x11-common и можно запустить разными способами. от форвардинга иксов, до lxc exec.
во-вторых ну иксы. и чё? ну ставить. и чё? а ещё комп желательно купить. с монитором. столько трат ради запуска.
как это к теме треда относится?

это зависимость совершенно другого уровня, нежели зависимости, от которых зависит выволнение опкодов в бинарнике k3b

А я и не про графику. А про сервис провайдеры например доступа к IPC или БД...

да, но срач то был про занимаемое место

Именно. Нужен просто слой абстракции.

Про поделки ms нечего говорить. Можно считать, что их и не было. Ms перестал их поддерживать - они сдохли. Всё. Не было такой технологии, не существовало никогда, никогда ничего не «взлетало» или «падало» (тем более, если там был какой-то «патент» на api или еще что-нибудь).

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

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

Syntax error „самодостаточный“ is not define.

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

ubuntu-minimal из https://cloud-images.ubuntu.com/minimal/releases/
~# apt install k3b --no-install-recommends
Need to get 90.2 MB of archives

90МБ это немного. Во-вторых, надо учитывать что там тянется много графики, не о носящейся к этой программе, например вся дефолтная тема иконок, например. А сам программный код с библиотеками занимает скорей всего где-то четверть или меньше.
Если бы пакет делался самодостаточным, он бы не тащил с собой всю тему иконок и прочую графику, а только то что используется программой. Но это зависит от лени собиральщика, могут и запихать весь Qt целиком и все кдешные иконки, ибо так быстрее.