Slackware 14.2 stable

Где там костыли для сборки с fakeroot?

Распаковывать надо под рутом. Дальше что? fakeroot предназначен для создания пакетов, это не руткит для их несанкционированной установки.

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

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

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

Просто придерживаюсь правил хорошего тона

обоснования которых мы так и не увидели.
ЗЫ Хотя я могу предположить «откуда ноги растут». Под рутом работать бэд, это все знают. Предполагается что пользователь работает не под рутовой записью, поэтому в сурсах в инструкцих по сборке всегда писалось что-то типа "./configure; make" и потом отдельно оговаривалось что «make install» выполнить из под рута надо. И пакетные сборшики пошли той же дорогой. А Патрик просто не стал. Но в целом не теплее не холоднее из под кого будет выполнен make.

1) после сборки ядрышка в /home/user/kernel/linux-версия и его установки симлинк /lib/modules/версия/build показывал бы на актуальные исходники в /home. Но реально симлинк ставится на /usr/src/linux-headers-версия-* (пакет linux-headers)
2) да и сам make-kpkg в jessie уже выкинули

в целом не теплее не холоднее из под кого будет выполнен make

Тут есть одна закавыка в случае кривого make install. Поясню.

Одна из распространенных операций подготовки дерева под опакечивание:
make install DESTDIR=/tmp/pkg

Допустим, апстримный разработчик зевнул и для некоторых файлов пролюбил $DESTDIR, использовав целью, например, $prefix/file вместо $DESTDIR/$prefix/file.

В варианте с fakeroot эта ситуация обнаружится по ошибкам записи в /usr/file (поскольку эффективных прав на запись туда у процесса нет). В варианте с root картинка будет хуже:
1) в системе, где была сборка, файл будет установлен мимо ПМ
2) пакет не получит файла,
3) на другие системы файл с пакетом не приедет,
4) воспроизвести сборщику проблему будет сложнее, у него-то file на месте.

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

Какие-то иные сценарии, где от fakeroot есть польза, вот так сразу в голову не приходят.

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

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

Нууу в чем-то убедили. Хотя на практике с таким не сталкивался, но вы правильно написали " от ошибок никто не застрахован".

хотя бы потому что превысить лимиты при сборке существенно проще.

Лимиты простите чего? Вы на боевом сервере всегда собираете?

Хотя с приходом overlayfs можно для контроля описанной ситуации пойти другим путем:
http://www.linuxquestions.org/questions/slackware-14/slackware-package-build-...

Лимиты простите чего?

ты правда про 5% никогда ничего?

Вы на боевом сервере всегда собираете?

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

ты правда про 5% никогда ничего?

Из ваших постов пока не понимаю.

Нет. Я не админ и у меня нету сервера. Но специально переключаться в рут для сборки

Часто собираете пакеты на локалхосте? И под какую ОС? Я серьезно.

Интересно. Спасибо за инфу!

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

Ты дурак. Как от сборки пакета может поломаться система? Что это за такая «случайность»? Во время сборки потрутся рабочие файлы, или конфиги перепишутся? Дебилизм.

Читаем выше от bormant Slackware 14.2 stable (комментарий)
Шансы испортить таки есть.

Ты дурак.

нет ты

Как от сборки пакета может поломаться система?

http://cboard.cprogramming.com/linux-programming/42383-never-compile-root.html

и далее в поисковик. Там ещё куча примеров.

Что это за такая «случайность»? Во время сборки потрутся рабочие файлы, или конфиги перепишутся?

а знаешь что случится если процессу потребуется запись в файл, а те 5% будут внезапно исчерпаны?

Дебилизм

+1

Из ваших постов пока не понимаю.

надо было документацию читать _до_ постов.

Часто собираете пакеты на локалхосте? И под какую ОС? Я серьезно.

лол кадлый день по три штуки. В субботу по два. Некошерно, знаю.

Ну этот-то пример вовсе ни в какие ворота не лезет:
1) некто неизвестно где взял тарбол
2) не проверил контрольную сумму
3) запустил от рута

Объясните уже мне, какая разница, когда сломал бы он себе систему:
1) на этапе make
2) на этапе установки вредоносного пакета (от root, без вариантов)

http://cboard.cprogramming.com/linux-programming/42383-never-compile-root.html

Атличное начало «And I am an idiot» Дальше в том же духе. Остальные примеры вы такие же приводить собираетесь?
ЗЫ И таки да, пост 2003-го года в те времена факапов могло быть реально больше.
ЗЫЫ Про 5% расскажете все-таки или нет?

ЗЫЫ Про 5% расскажете все-таки или нет?

Вероятно речь про: https://wiki.archlinux.org/index.php/ext4#Reserved_blocks

Если это действительно так, то owainaiy «большой оригинал». Могбы сразу с патча бармина начать.

Атличное начало «And I am an idiot» Дальше в том же духе.

«А я не такой, я не такой, я не такой! Специально захожу под рутом для сборки пакета, но я не такой, я не такой, я не такой!»

Остальные примеры вы такие же приводить собираетесь?

Научишься пользоваться поисковиком - сам найдёшь.

ЗЫЫ Про 5% расскажете все-таки или нет?

А оно тебе ннада?

Атличное начало «And I am an idiot» Дальше в том же духе.

«А я не такой, я не такой, я не такой! Специально захожу под рутом для сборки пакета, но я не такой, я не такой, я не такой!»

Надо было так ответить:

А я не такой, я не такой, я не такой! Специально найду причину, если мне чего то не нравится/не могу понять, но ведь я идиот, я идиот, я идиот!

Объясните уже мне, какая разница, когда сломал бы он себе систему:

2) на этапе установки вредоносного пакета (от root, без вариантов)

А как можно сломать себе систему на этапе тестовой установки? Это же делается в контейнере. Ну ладно, systemd в слаку не завезли, но lxc-то имеется?

А как можно сломать себе систему на этапе тестовой установки? Это же делается в контейнере.

Slackware:
-- от пользователя: разработка и тестирование, оформление слакбилда
-- от рута: тестовая сборка пакета в контейнере/overlayfs
-- от рута: тестовая установка в контейнере

Использующие fakeroot:
-- от пользователя: разработка и тестирование, оформление deb.src/spec/...
-- от пользователя: тестовая сборка пакета
-- от рута: тестовая установка в контейнере

Тут анекдот про монашку, свечку и презерватив.

После выхода «Windows 10» использовать эту ОС уже опасно, так как она просто напросто тупо за Вами следит.

Десятка это один большой троян. Да еще и нестабильна.

лол кадлый день по три штуки. В субботу по два. Некошерно, знаю.

Заткнись, и собирай пакеты от суперпользователя.

Всякие хмыри, как ты будут ещё тут пытаться опровергнуть вековое юниксовое правило.

Надо было так ответить:

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

- Не вижу причин не зайти под рутом для компиляции

- Только идиоты компилируют под рутом

- Пруфлинк или не идиоты

- хттп://пруфлинк

- Так то же был идиот!!!

Выдергиваете из контекста. Идиот не в том что компилировал из под рута, а в том что взял хз что, хз где... Разница надеюсь понятна?
Я выше уже намекал про патч бармина, запуск которого и из под юзера может доставить «попоболь» запустившему.

- Только идиоты компилируют под рутом

- Пруфлинк или не идиоты

- хттп://пруфлинк

- Так то же был идиот!!!

Ну и с чего ты так «хихикаешь»? Или скинуть тебе видос где велосипедисты-каскадеры ломают себе кости, сказав при этом, что «едут на велосипеде только идиоты, потому что езда на велосипеде калечит»?

Тут холивар: сборка->под пользователем, установка-из-под-рута vs все-из-под-рута :)

Вот именно. Причём холиварствующие не приводят никаких доводов, кроме «так принято». От себя могу сказать: я ни одного пакета с нуля не собрал, пробовал только пересобирать, внося изменения, как под рутом, так и под пользователем, нет, система от сборки под рутом у меня ни разу не угробилась, но это ещё не повод считать этот метод правильным.
Так же пробовал устанавливать программы через «make install», когда программа нужна срочно, а в виде пакета её нигде нет, а опакетить её сам ты явно не осилишь. Но при этом я считаю, что устанавливать программы через «make install» - действие неправильное, несмотря на то, что в линуксе десятилетней давности так принято было делать: во-первых программу, установленную таким образом сложно удалить из системы, во-вторых - это потенциально-опасное действие, make-сценарии никто не читает, мало ли какие ошибки они могут содержать. «make install» устанавливает программу, копируя её файлы обычно в /usr, но /usr - это каталог неизменяемых файлов, писать что-либо в него нельзя, единственная программа, которой должно быть дозволено писать в /usr - это запущенный из-под рута пакетный менеджер. Поэтому мы должны всячески воспрепятствовать сценарию сборки и установки обойти этот запрет: компилировать под юзером, вместо установки дать «make install» установить всё не в /usr, а куда-нибудь в /tmp, а ещё под fakeroot и в chroot-окружении, а лучше вообще не делать «make install», а вычислить какие файлы скопировались бы при этом действии, и скопировать с помощью cp, а потом закатать в пакет.

но /usr - это каталог неизменяемых файлов, писать что-либо в него нельзя,

«Дайте две». И чего же «производители дистров» до сих пор не монтируют его в ro по дэфолту? Даже наоборот, теперь новая мода, «считается что usr отдельно это бэд» и он должен быть в корневой системе.

устанавливать программы через «make install» - действие неправильное, несмотря на то, что в линуксе десятилетней давности так принято было делать

....

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

Т.е. «10 лет назад» у программистов «руки были прямее» - так и запишем.
По вашей логике пора начать бояться набирать make install modules_install

Мелочь же, ну. Имхо, хуже вот что: нет единого репозитория. Патрик отдельно, AlienBob отдельно, Willy S.R. отдельно, GNOME team отдельно, Stuart W (slackarm) отдельно, slackbuilds.org отдельно. Довольно неудобно, в итоге. Дублируются усилия, изобретаются велосипеды (slackpkg+). Вот взялись бы все за руки, да Патрик эгоист.

Вы и правы и нет.
Нет, потому что: У других дистров же такая же чехарда с stable/unstable/кучей-левых о чем здесь частенько можно прочитать жалобы от их пользователей.
Да, потому что: конечно хотелось бы большего порядка в части сторонних пакетов для слаки в 2016 году. Причем именно сторонних, ибо Патрик прав «что сам не ел, то и вам не дам».

По вашей логике пора начать бояться набирать make install modules_install

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

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

Я вообще-то про пересборку ядра с опциями которые мне «любимому» нужны и которых дистростроитель не включил/выключил. Повторю вопрос. Мне что, этого тоже начать бояться?

Нет, потому что: У других дистров же такая же чехарда с stable/unstable/кучей-левых о чем здесь частенько можно прочитать жалобы от их пользователей.

Я не понял о какой ты чехарде. Мне кажется, что от объединения всех этих людей в единый репозиторий, на базе которого и собиралась б слака - никто не проиграет. А то сейчас slackware и slackware live - отдельные проекты, чушь. Чтоб собрать себе дистрибутив, нужно sync'ать нужное не из единого репозитория (отбросив ненужное через EXCLUDE), а клонировать каждый проект отдельно, да еще заниматься интеграцией. Willy уже проделал похожую работу, собрал образ с cinnamon'ом. AlienBob проделал похожую, собрал live cd. Мне, если нужно отличное и включающее - нужно опять делать похожую работу. Каждый изобретает колесо.

Патрик прав «что сам не ел, то и вам не дам».

Прав. Но если б он повернулся в сторону открытой модели разработки, был бы еще больше прав.

Простите, возможно я не очень понятно выразился. Я хотел сказать:
1. слака от Патрика как оно есть оставить, благо стабильно.
2. вот сторонние репозитории действительно не плохо бы привести к «общему знаменателю».

Они в основной массе не пересекаются, о каком дублировании может идти речь? Каждый поливает свою тыкву. Хранилища формализованы, есть slackpkg+, этого вполне достаточно.

должны ... должен ... должна

Вот и займитесь. Проверим на практике цену вашим утверждениям.

Вы категорически не правы в том, кто что делает.
На самом деле работы взаимодополняющие, а не дублирующие. Эрик подготовил liveslak — сценарии на базе Slackware, которым по барабану, что именно собирать в живую систему. Вилли подготовил пакеты корицы, Эрик подготовил KDE5, сценариями собрал варианты живых систем. Авторы zenwalk и salix пустой пересборкой пакетов от Slackware тоже не занимаются. Ники собрал MLED, добавляя отсутствующее. Дублирования уак такового практически нет, распыления сил нет.
Зато и мера ответственности велика, понятно кто что и как сделал.

Вопрос как к знатоку. Что скажите про sbotools и slpkg в части использования sb ?

Вот тут промашка вышла, я ими не пользуюсь, потому ничего определённого сказать не могу.
Не пользуюсь не потому что что-либо с ними не так, а просто какой-то насущной потребности в них на фоне slackpkg/slackpkg+/sbopkg/руки не возникало, а любопытство дальше чем просто почитать про них не завело.

Жаль. :) Я вот на фоне этой темы решил посмотреть чего еще не познанного мной есть, потыкал палочкой, но вот понять плюсы/минусы с sbopkg не могу, в инете читать сравнения лениво думал вы в курсе :)

А есть какие-то годные аналоги sbopkg?

Так я и спросил про sbotools и slpkg :) И так же написал что «в инете читать сравнения лениво» :)

ааа, ок

А есть какие-то годные аналоги sbopkg?

ЛЮБОЙ slackBuild есть «годный аналог» для чего угодно. ВАЖНО что бы в системе были необходимые библиотеки и проверка скачиваемого исходника. И, может быть проверка этого slackBuild... Подозреваю возражения - ПРОВЕРКА, а я не спец в slackBuild. Тогда SlackWare не для вас... Пользуйтесь ubuntu и т.д.

На моей памяти (Уже Slackware 14.0 /да старо.../) в системе множество пакетов не sbopkg. Ничего. Живем и здравствуем :) Важно ставить то что необходимо для работы.

P.S. Какая разница - sbopkg или не sbopkg? Важно - ОС должна работать на вас.

Куда-то вас не туда понесло.
sbopkg автоматизирует сборку со slackbuilds.org, вопрос был про аналогичные инструменты.
Кстати, остался не упомянутым slapt-src и sourcery.