Сборка дебиановский source пакетов

checkinstall?

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

Добро пожаловать в Slackware! Там пакеты собираются буквально двумя командами и представляют собой просто архив, который распаковывается в корень. В своё время пользовался этим дистрибутивом в том числе из-за простоты сборки своих пакетов.

dpkg-buildpackage

да, это уметь надо

make install

угу, 20 лет назад мы от этого ушли, и вот опять.

В своё время пользовался этим дистрибутивом в том числе из-за простоты сборки своих пакетов.

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

Есть вариант делать make install не в /, а в ~/.local. Сам так и делаю, чтобы не засорятся.

cmake -DCMAKE_INSTALL_PREFIX=/opt/anyshit .. && make install

/thread

тогда засоряется ~/.local

угу, 20 лет назад мы от этого ушли, и вот опять.

Потому что хочется, чтобы пакеты собирались по кнопке «сделать хорошо». В коей-то мере это решается за счет checkinstall. Но тогда надо внимательно смотреть, как разбили на пакеты в дистрибутиве, чтобы если какой-то другой пакет будет иметь устанавливаемый пакет в зависимостях, то чтобы все нашлось как надо.

А make && make install как раз ближе всего к концепции максимально простого в использовании инструмента. Следом идет checkinstall, но там уже что-то руками делать надо

Если заглянуть в ситуацию чуть глубже - то в чем причина вообще фейла сборки пакета deb-ом? Она может быть только в одном - dpkg-buildpackage не обеспечивает повторяемость сборки. Потому что если бы он ее обеспечивал, пакет единожды своим автором протестированный собирался бы всегда и везде и в последующем.

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

Чтобы это решить, нужен другой пакетный менеджер где этих проблем нет by design - например Nix.

Я бы сказал, что проблема еще глубже. Подход, применяемый в винде и макоси, когда каждое приложение живет в своей отдельной директории, а не раскидано по куче директорий (bin/, lib/, share/) куда адекватнее. Потому что в таком варианте ничего не засоряется даже вообще без пакетного менеджера, т.к. все лежит компактно.

Я бы сказал, что проблема еще глубже. Подход, применяемый в винде и макоси, когда каждое приложение живет в своей отдельной директории, а не раскидано по куче директорий (bin/, lib/, share/) куда адекватнее

Да, но Nix еще адекватнее. Там все как бы изолировано, независимо и друг друга не засоряет, и в то же время сохраняется разделение на пакеты и дедупликация одинакового между приложениями.

Но ведь давно уже не живет целиком в одной.

В профиле пользователя как минимум гадит, ProgramData, еще каких-то папок в винде нагородили, тысяча их.

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

Но это совсем не проблема, если она пишет по предсказуемому адресу вида ProgramData/<ProgramName>

Корень то проблемы, о которой я говорю в том, что если во времена Unix программа это чаще всего был просто 1 файл бинарник, то теперь программа содержит в себе много файлов. А подход во многом остался прежним. Оттого и помойка в bin/ и lib/

В профиле пользователя как минимум гадит

Нууу если сейчас проблему дот-файлов в линуксе поднять то вообще печально станет.

я знаю, чего тебе хочется. чтобы и линукс, и для домохозяек. («я не такой как все, а думать мне сложно») я собирал софт почти под все, что есть. держал и deb, и rpm репы... просто писать лень.

checkinstall

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

Подход, применяемый в винде и макоси... куда адекватнее.

все ок! корпорации уже давно услышали нытье «обычных пользователей» и делают линукс по образу и подобию этих двух ОС. просто пока еще не...

у сусе был билд-сервис под все платформы. может, там можно че-то такое делать, как тебе нравится.

я знаю, что тебе хочется. чтобы и линукс, и для домохозяек. я собирал софт почти под все, что есть. держал и deb, и rpm репы… просто писать лень.

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

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

Какие паки? Вот есть гитхаб репозиторий с новой версией нужной мне либы. Делаю гит-клон, собираю с помощью cmake, make - все собирается. Делаю dpkg-buildpackage - не собирается

да, это бывает. но вот девелоперов, которые вечно пишут софт на последних либах, я не люблю. вечно их софт потом требует федору или арч для работы.

Какие паки?

типа chroot окружения. внутри более свежий софт.

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

Под каждую либу городить chroot окружение? Это говорит о более чем плохой организации структуры системы

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

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

а «необходимые улучшения» - это новые модные фишечки

Нет.

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

Можно на это посмотреть с другой стороны.

Желание заюзать последнее лично я считаю вполне естественным и так делаю. Но я не могу понять, почему убожетсво такой вещи как deb должно приводить к тому, что программисты пишут на старье? Не проще ли починить один пакетный менеджер, чтобы он выполнял свою функцию как требуется, чем каждому программисту в мире корячится на устаревшем?

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

Новые библиотеки могут реализовывать новый функционал или исправлять старые проблемы. И далеко не сразу все это попадает в дистрибутив. С примерами этого я сталкивался не раз и не два.

все, что вас интересует, - это фигачить код

В целом, да.

а сисадмина интересует, что потом с этим всем делать и как это потом куда-то ставить

Естественно.

просто кое-кто не умеет собирать пакеты

Да, именно так. Вместо того чтобы собирать нормальные пакеты типа Nix, кое-кто собирает изначально убогий deb, который не может решить основную задачу by design. Вот эту проблему надо решать, в том числе и при помощи мейнтейнера.

пакеты типа Nix

что это? [сарказм]

изначально убогий deb

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

который не может решить основную задачу

есть статистка по использованию в продакшене. SUSE представила единый сервис поддержки дистрибутивов от SUSE и Red Hat (комментарий)

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

Можно и зайца научить курить. Это не значит что это делать нужно, тем более - всем нужно. Я могу на третьем дебиане софт разрабатывать, но я не вижу ни одной причины почему так нужно делать.

есть статистка по использованию в продакшене

В основном на серверах, а на десктопах линукс в пределах погрешности. На десктопе эти проблемы намного острее. На сервере у меня сейчас debian 9 и я не вижу причин его обновлять, потому что софт который там работает - по сути (используемым функциям) тот же, что и в debian 11, практической разницы не будет.

Но на десктопе я не поставлю debian 9 в 2022 году - другие задачи и требования.

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

И далеко не сразу все это попадает в

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

просто тебе больше нравится, что в новых уже есть готовое

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

Можно и зайца научить курить. Это не значит что это делать нужно,

у тебя дата регистрации 2020 год. последние 20 лет эти задачи успешно решаются. и ты мне рассказываешь, как должно быть? тебе самому не смешно? заяц тут - ты.

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

my point exactly! ты не видишь, потому что ты хочешь только фигачить код. у тебя какие-то свои мифы насчет nix в голове. а проблема доставки твоего софта в твою голову не помещается!

Вот мы программисты сволочи.

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

у тебя дата регистрации 2020 год

Ну да. Как христианином становишься только после крещения, так и линукс поставить можно только после регистрации на ЛОРе. Хорошая шутка. Тем более что у меня дата регистрации совсем не такая которую ты видишь.

тебе самому не смешно? заяц тут - ты.

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

а проблема доставки твоего софта в твою голову не помещается!

Помещается как раз. Я эти проблемы решаю в том числе и с доставкой под дебиан и убунту, еще больше проблем (с другими дистрибутивами) решают мейнтейнеры которые собирают мои софтины. Это в твою голову проблемы разработчика совсем что-то не помещаются. Код же с неба не падает, это работа, и естественно использовать инструменты которые сокращают этот объем работы.

То, что все привыкли страдать фигней и для простейшей задачи «нанимать» армии мейнтейнеров совсем не означает что это рационально и так и надо жить.

а трахаться с ним потом должны другие

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

Мне конечно же смешно

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

Я вообще не понимаю

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

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

Но это совсем не проблема, если она пишет по предсказуемому адресу вида

В том-то и дело что не всегда. У меня есть вендософт, который смотрит свой конфиг в четырех разных местах. :)

Я так-то не защищаю того что сейчас в линуксе творится, но мне думается оно в той или иной степени везде сейчас так, ввиду усложнения софта.

James_Holden имеешь ввиду, что по уму все должно быть в .config, но не все следуют?

Так-то согласен, но дотфайлы они хотя бы в пределах хомяка все.

почему вы не можете опакечивать свой софт

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

Хуже того - это ломает все не сразу, например при тестировании перед релизом все будет собираться, а дальше - гарантий нет вообще, потому что повторяемость сборки deb пакета созданного по правилам дебиана не обеспечивается by design.

имеешь ввиду, что по уму все должно быть в .config, но не все следуют?

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

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

p.s.

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

гггг, политические беженцы на лоре!) не политика же поменялась, а ты стал адекватнее себя вести=)

я просто ставлю под сомнение здравость твоих суждений, после того, что случилось:)

Это странно, я честно не вижу связи.

политические беженцы на лоре!)

Скорее политические психи.

не политика же поменялась, а ты стал адекватнее себя вести=)

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

проблема ТС в том, что он вообще не смог воспользоваться системой сборки. никаких проблем там со стороны Debian нет, но есть свой язык описания этого всего.

я не очень понимаю, про какие требования со стороны Debian ты говоришь и не могу сказать, правда это или нет. в любом случае, если ты делаешь enterprise решение, то у нас есть RHEL, который все это регламентирует.

Это странно, я честно не вижу связи.

(по глупости)

и все-таки связь, наверное, есть. хотя ты ее и не видишь:)