Обновляйте glibc через $DESTDIR

А я люблю представлять, что я скрипт для сборки, и вручную выполнять все команды. На две команды целый день уходит…

Ты просто не любишь конпелять так же, как любим мы.

Обновляйте glibc через $DESTDIR

Обновляйте Glibc через пакетный менеджер. /thread

Не всем нужен пакетный менеджер.

тебе - нужен, как доказывает эта тема

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

тебе - нужен, как доказывает эта тема

Так я же обновил glibc без пакетного менеджера.

Не всем нужен пакетный менеджер.

Не всем нужен Интернет.

Не всем нужен компьютер.

Не всем нужно электричество.

Не всем нужен водопровод.

Не всем нужна термическая обработка пищи.

Не всем нужна одежда.

Не всем нужно прямохождение.

🐒

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

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

Вот я и рассказываю то, о чём молчит документация. А то, мало ли, кто-нибудь будет думать, что у него в системе где-то грабли есть, и будет долго их искать. А тут дело не в этом, а в том, что если раньше glibc обновлялся по LFS Book, то теперь LFS Book недостаточно.

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

если в документации к пистолету не написано «не направлять себе в глаз» - всё равно ты облажался

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

Пакетники? Нет, не слышал.

а в каком LFS написано делать просто ./configure без параметров при сборке glibc?

Сравнение некорректно. В документации написано.

./configure && make && make install

./configure && make && DESTDIR="newglibcdir" make install

И вот эти вот изменения не описаны в документации.

Это сокращение шагов, очевидно же. Параметры указаны в книге.

Сравнение некорректно

корректно.

В документации написано

серьёзные дяди, собирающие системные компоненты не читают эту документацию

make && make install

Всегда удивляло зачем надо вызывать make 2 раза если одного make install достаточно?

make DESTDIR=$LFS install

https://www.linuxfromscratch.org/lfs/view/development/chapter05/glibc.html

Но причём тут хардкодит префикс? По дефолту если без параметров вообще запускать, то префикс вообще будет /usr/local. Это же поведение самой системы сборки такое.

вообще make без параметров - равно make all, вряд ли в make install входит запуск make all

Я имею в виду запустить сразу make install. Он обычно перед установкой всё собирает.

Даже Патрик читает .spec файлы Федоры.

Ну и обратите внимание на часть книги. Это описание сборки промежуточного тулчейна. Сборка glibc'а для системы описана в другой части книги.

Тогда как минимум доку по glibc читай - там про DESTDIR тоже есть.

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

и каким образом make install проверяет надо ли сделать пересборку?
То есть если ты собрал из исходников что-то, потом внес правку в исходники, то make install должно пересобрать заново измененный исходник? Почему?

Но раньше всё работало и без этого. А теперь поведение изменилось. Я-то теперь об этом знаю. Сообщаю тем, кто ещё не знает.

то make install должно пересобрать заново измененный исходник? Почему?

У меня пересобирает. Или кривые autotools это не умеют? Если поменять файлы сборки, то тоже пересобирает как надо.

вообще можешь посмотреть любой макефайл. make install делает make all и шаги для установки.

УМВР.

Правда у меня /lib -> usr/lib

В LFS?

А у меня так:

> file /lib64
/lib64: symbolic link to lib
> file /usr/lib64
/usr/lib64: symbolic link to lib
>

Компьютером и интернетом вполне можно пользоваться без пакетного менеджера и юникодной локали.

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

Не всем нужен glibc.

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

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

Водопровод тоже необязателен. Особенно если мыться не чаще раза в неделю.

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

А все остальные применения ты запрещаешь? Свободное ПО (за которое ты, между прочим, топишь в соседней теме) — оно про разнообразие. Я вот считаю, что опыт ТСа может неожиданно оказаться востребованным, в том числе людьми, которые этого не ожидали. Пусть экспериментирует.

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

Ну, применения могут быть либо серьёзными, либо несерьёзными, A ∪ ¬A = U. Я не предлагаю ничего запрещать, просто выражаю мнение, что для серьёзного применения нужен пакетный менеджер, а использование дистрибутива без оного — это как когда «коту нечего делать». А так, конечно, пусть эксперементирует. Может даже заняться портированием Метапрога для работы в ядерной консоли.

и каким образом make install проверяет надо ли сделать пересборку?
То есть если ты собрал из исходников что-то, потом внес правку в исходники, то make install должно пересобрать заново измененный исходник? Почему?
★★★★

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

необязательно в install будет правило выполнить make all. Makefile может быть любым в общем случае, обязательного all в install нигде не прописано.

необязательно в install будет правило выполнить make all.

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

Это, конечно, если make’ом пользовались как make’ом, а не вызывали баш-портянки на питоне.

make all же делают, потому что кроме артефактов в all может быть прогон тестов и ещё какая-нибудь не существенная для инсталляции, но принятая в проекте побочная активность.

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

у софта со временем появляются новые особенности, которые не до конца отражены в документации

Я б сказал у софта со временем иногда появляется документация, и именно в таком порядке

Не всем нужна нужность. Саахрикту — божество. Именно он и сотворил пространство-время где и появились причинно-следственные связи.

Саахрикту не пьянеет! Когда он выпьет опьянеет алкоголь.