|
|
Предимногословие
Сделано из нескольких сообщений в fido7.ru.linux.chainik в качестве попытки зафиксировать ряд объяснений того, как живёт, окультуривается, разворачивается, обновляется и порой умирает пресловутый линуксовый софт.
Почему "линуксовый"? Потому, что по большей части тут сознательное абстрагирование от того, что с ним делается в более других системах, чем те Linux-based, которые можно называть управляемыми.
Да, это всё может перекраиваться, поскольку тред и статья заметно различаются размерностью. ;-)
Благодарности:
- Roman Komissarov (грамотная постановка вопросов, начиная с "как поставить … на Ubuntu" и явно вдумчивое восприятие ответов)
- Victor Wagner (много раз вспоминал его статьи и письма по ходу написания)
- Vladimir Bormotov (человек, разъяснения которого в своё время помогли перестать бояться RPM и его *.spec)
- Alexandre Prokoudine и Alexander Dymo за обсуждение
- многим другим, приложившим руку к формированию этих соображений (да и почвы для них в виде собственно программного обеспечения in question)
—
Michael Shigorin
В начале был… нет, *этого* тогда точно не было
> и "репозиторий".
"Депозитарий", "лепрозорий"… в данном случае — сборище пакетов
и лежащая рядом с ними метаинформация (в случае apt это каталог base/).
Нормальный репозиторий содержит пакеты, которые по своим зависимостям
не выходят за его рамки (плюс, возможно, базового — e.g. main для
universe там или main для contrib у нас).
> >> А что за зверь universe?
> MS> Hа сидюшку они вроде как репозиторий main кладут, соответственно он
> MS> ограничен её объёмом. А остальное собранное как надо по понятиям
> MS> дистрибутива доступно в другом репо совершенно отдельного объёма.
> MS> (в unstable ихнем это сейчас, кажется, 7.5Gb)
> Hифигасебе! То есть браузеры-почтовики-игры-прочую лабуду они на CD
> умудрились напихать, а жизненно важный компилер - нет?
К небольшому компилеру идёт большой (и главное — заранее
непредсказуемый как для заданного лимита объёма) пучок библиотек,
точнее, *-dev (*-devel).
> Лучше бы второй CD не live делали тогда, а с ним.
Не, не лучше. У нас играться в "разработку на втором сидюке" давно
прекратили, от лукавого это — сейчас даже для однодисковых
дистрибутивов настольного исполнения делается фиксация полного contrib.
> А что, интересно, на 7.5гб нужного и важного? У меня винХР
> с програмфайлами занимают 3, и это при том не архив.
Посмотрите на packages.debian.org, что ли.
Дополнение: также было упомянуто, что оптимально иметь такой репозиторий в _полном_ виде под рукой, но даже если это нереально — обычно и с модемом использовать готовую пакетную базу проще, быстрее и выгоднее, чем таскать тарболы и собирать уже собранное.
Дело не в том, что нужно всё, а в том, что когда что-то нужно —
лучше пусть оно будет в быстроразогреваемом виде, а не "готово для
разморозки, разделки, посыпания специями, тушения, установки на стол".
Соответственно люди, которые озадачились нормальным приготовлением,
разумны, когда скидываются рецептами, а не изобретают их каждый раз
с нуля.
А вот здесь он на сцену и выходит
> >> и "репозиторий".
> Ага. То есть набор программ, притом самодостаточный.
Угу. Также говорят "замкнутый" (в этом плане).
> Что мне мешает выбрать их самому?
Программы? Да ничто, кроме бессмысленности занятия. :)
Пояснение. Исходный вопрос касался того, "как собрать программу из тарбола на Ubuntu 5.04" (после ряда уточнений); соответственно как бессмысленное характеризуется занятие выбора программ посредством их компиляции, когда существуют готовые сборки для заданного дистро.
> Hестыковок с версией линукса я пока не боюсь, не заработает - потру.
Нуу, погуглите вопросы, на которые отвечают "а посмотри, есть ли там
make uninstall", и в окрестности. Это касательно "потру" дикорастущих
установок (которые действительно лучше всего пылесосить под корень).
[…]
— так может иметь смысл сформулировать, какие есть умения, и хоть
сюда (или в тамошние рассылки/форумы) забросить с вопросом "куда бы
их приложить для пользы". Глядишь, кто-нить в какой проект затащит
и польза начнётся. :)
> >> умудрились напихать, а жизненно важный компилер - нет?
> MS> К небольшому компилеру идёт большой (и главное — заранее
> MS> непредсказуемый как для заданного лимита объёма) пучок библиотек,
> MS> точнее, *-dev (*-devel).
> Странно. Я в программировании, конечно, от нуля недалеко, но зачем
> пучок библиотек? Язык один, результат (ехе) должен быть однозначным.
Языков много, задач много, способов решения одной задачи — тоже много.
К тому, что в линуксе зоопарки процветают — можете привыкать сразу :-)
> Или там библиотеки для разных версий ядра? Тогда он не к каждому
> дистрибутиву должен быть свой, а один на всех…
Не, ядро обычно (но не всему) ортогонально как раз. Можете глянуть
people.redhat.com/drepper/dsohowto.pdf по части разъяснений
про API/ABI.
И главное — зачем?
> Как в данном случае мог помочь репо?
В нём мог оказаться либо сразу собираемый, либо то, что ему требуется
для сборки. (установка zlib или иных системных библиотек из тарбола
при живых родных пакетных — как минимум чревато недоразумениями,
как максимум — что-то не просто отвалится, а заклинит систему целиком)
Пояснение: да-да, процесс сборки софта из тарбола тоже может — и обычно требует — нуждаться в дополнительном софте. При этом усилия, потраченные в сумме на получение методом самостоятельной сборки, обычно не стоят усилий (времени, денег), потраченных на получение готового пакета, если он уже существует.
А если уж мы решили брать программы уже приготовленными, а не собирать на коленке — то интересней там, где их много и приготовлены они хорошо; и вот тут и вернулись к самому первому ответу на исходный вопрос — "где брать программы для своего дистрибутива?".
> >> Без ликбеза не могу понять. Что за фиксация contrib?
> MS> Hу, выпускали ALT Linux Junior 1.x — один CD и всё, помнится.
> MS> Hекоторые запасливые товарищи предусмотрительно пооткладывали
> MS> в сторонку срезы unstable тех же времён и в результате имели полный
> MS> набор пакетов, включая разработку с библиотеками и прочее.
> То есть что-то отбрасывалос, заменялось новым
В рассматриваемом — нет. В поехавшем дальше unstable — да,
из-за чего он терял бинарную совместимость с этим самым одним сидюком.
Но это отдельная история…
> но при этом для работы этого нового нужно было старое?
Нет, не туда.
[…]
> MS> К Compact 2.3 наконец-то вняли двухлетним примерно предложениям
> MS> да заморозили при отведении ветки unstable для 2.3 уже полный срез.
> MS> Соответственно то, что не вошло на диск — было опубликовано как
> MS> contrib.
> А насколько содержимое contrib совместимо по версиям?
Между собой? Настолько, насколько упорядочено было в unstable,
из которого делался срез.
> Hе переписывали же его под 2.3 с чистого листа?
Как бы это пояснить… примерно так (большинство версий, кроме
2.4, выходили [и] в варианте 1CD):
---*------*------*------*------*------*------*------*---->Sisyphus
1.0 1.1 2.0 2.1 2.2 2.3 2.4 3.0
`>cd2 `>cd2 `>ctb | `>ctb
full full `>full
Sisyphus (unstable), из которого делаются x.y — собственно то,
что разрабатывается. По мере надобности его подзамораживали
(объявляли определённые ограничения на резкие изменения, например,
залитие сильно новых и переработанных версий библиотек, которые
требуют пересборки всего зависимого от них хозяйства, ну и более
тонкие по мере заморозки).
Но так как не всем интересно в морозилке, то рано или поздно
отпочковывалась ветка, которая долизывалась отдельно и в итоге
выпускалась на одном или более блинах как дистрибутив.
При этом остаток мог быть просто уронен на пол после выпуска
(как было с 1.x, 2.1 и отчасти с junior-2.0), а мог быть подметён
насчёт откровенно сломанных пакетов (например, требующих уже вытесненных
новыми версий библиотек — такие и не установятся) и выгружен в полный
contrib, доступный ну хотя бы на ftp.
> Hаверняка contrib под 2.0 сильно повторяет 2.3?
Не угадали, общего там — названия многих (не всех!) пакетов и текстовые
строчки из интерфейсов, где и их не перепахали за несколько лет в первую
очередь непосредственные разработчики (это которые тарболы дарят).
Главное же — бинарно они несовместимы, за этот срок серьёзно изменились
многие системообразующие библиотеки, начиная прям с glibc.
> MS> (здесь вышел "полный" Master 2.4, там отдельный сказ, но всё на
> MS> плитках) Сейчас вон Compact 3.0 выпустили (в печати вроде), там та же
> MS> история — не вошедшее на сидюшку названо contrib (на DVD9 лежит
> MS> рядом).
> Идея ясна, но к чему такой геморрой? Hеужели проще переделывать
> гигабайты софта под версию, чем сделать версию "совместимой сверху
> вниз"?
Не всегда это возможно. Впрочем, хорошо написанный софт требует
максимум пересборки в изменившемся окружении[1], а вот новомодные
свистелки и неустоявшиеся проекты, которые за месяц могут измениться
до неузнаваемости — да, это геморрой, поскольку бывают ситуации,
когда в заданный промежуток времени софтA может требовать для сборки
новую библуB, которая при этом требует новую библуC, с рантаймом
(не -devel! "потребительской" частью) которой, однакоже, может
взрываться софтD, который должен работать в паре с софтомA.
Конкретно эта ситуация — не из частых, но это один из пробных камней
для различных подходов (да и дистрибутивов). Например, с полгода тому
фряшники знакомые плакали, что во freebsd ports наступили как раз на
такой клин — в apache2 очередная дырка (внимание, он из тех же портов),
а в mod_perl2 под самый 2.0 уехал API. Соответственно то, ради чего
всё это барахло вообще-то стоит (скрипты, в т.ч. заказчиков, которые
платили за написание, но не переписывание) — взорвалось.
Соответственно с репозиториями это решается тем, что есть такая штука,
как стабильный выпуск и несущественные по части функциональности
обновления к нему (sec updates и errata обычно, а не "новая версия
вышла, держите"). И при перевозе работающих систем с работающей,
но прекращающей поддерживаться ветки на текущую поддерживаемую есть
возможность провести тестовые миграции, зная состояние, версии и имея
возможность к ним привязываться.
Системы с портами (Free/Open/NetBSD, Gentoo) экономят на ветках,
а в итоге — на своих пользователях в подобных ситуациях.
Ну, типа, все, кто не-тормоза, давно поняли, что разработчикам нужна
своя песочница (причём далеко не только basesystem), а пользователям,
особенно платящим и "чтоб работало, слышишь?" — своя.
Вот. Приплыли к ещё одному ответу на не заданный явно, но уже сквозящий
вовсю вопрос — "зачем обновляться?". В смысле "куда ползут версии?".
Софт, который работает и при этом не является тривиальным, зачастую
всё-таки содержит ошибки, которые находят порой через годы после того,
как была выпущена и много-много где выставлена в работу заданная его
версия. Порой эти ошибки позволяют сделать с софтом то, чего позволять
нельзя — например, получить удалённый шелл (псевдопользовательский или
рутовый, в зависимости от пачки факторов).
Так как работать приходится, а успешным выводом "hello world!"
требования к программным комплексом обычно даже и не начинаются,
а языки вроде C/C++ достаточно бестолковы по части избежания таких
вот казусов — данностью является то, что через сколько-то лет
практически любая заданная версия заданной программы оказывается
в ситуации "известны дыры".
Так как за прошедшие годы разработчики не всегда сидят сложа руки,
то обычно прикручивать всё новую и новую требуемую функциональность
к софтине под вопросом её разработчикам становилось иначе — например,
вместо своего парсера воткнуть появившийся библиотечный (и заодно
исправить неудачные идеи по формату конфигов, выявившиеся при разработке
и эксплуатации той ветки N-летней давности). Ну и так далее.
Соответственно новая версия, скорее всего, будет не сильно похожа
на старую как минимум с точки зрения библиотечных требований.
Из-за стопки подобных эффектов "окно совместимости", в рамках которого
удаётся разумными пинками поддерживать некоторый ареал софта в рабочем
состоянии — составляет порядка года-двух естественным образом.
Более длинные сроки поддержки (до пяти лет на данный момент) держатся
в основном на инженерах, которые живут на деньги заказчиков тех самых
Red Hat и SuSE/Novell и заняты безусловно полезным, но ни грамма
не интересным трудом по исправлению старых, уже не развивающихся версий.
В общем-то, это второй полюс относительно "экватора" — противоположный
Gentoo и прочим "безумству смелых поём мы песню".
И, к сожалению, возомнившие себя могущими отрицаться всякой
ответственности участники IT-науки, индустрии, отрасли непохожи
на тех, кто готов создавать системы, которые не требуют поддержки
и обновлений. Да и не потянет уже человечество слезть с этой иглы,
слишком много вбухано по дури и неразумию, слишком много поставлено.
"А в остальном, прекрасная маркиза…" :-)
Бишь да, геморрой, но как-то едет.
[…]
> Ладнно, не я разработчик, чего разговаривать…
Э, не. ./configure && make — требует разработческих тулзов, даже если
не умений. Причём вследствие того, что имеют место быть стеки библиотек
— то, что софтинка для сборки хочет невинных пару других пакетов, может
вылиться дословно в *десятки* нетривиальных задач.
[…]
> >> ЗЫ: я таки нашёл какой-то gcc, v3.4.3. Где глянуть, подойдёт ли и
> >> как ставить?
> MS> Где нашли и в каком виде?
> Hа диске к хурналу. В виде tar.gz, но могу и распаковать. Только уже
> не надо - нашлось в поставке, теперь затык в GLIB.
В glibc? См. рис. 1.
Кстати, мой первый всерьёз (в смысле действительно проще переустановить,
чем выцарапать из бездны) убитый линукс был обязан смертью бинарному
пакету xmms-0.9, собранному с более новой glibc — после нездравого,
но хоть какого-то рассуждения и "а, была не была" glibc была обновлена
с той же плитки базарного RH5.9 (с надписью "RH6.01", разумеется), что
и xmms. В итоге не работал даже ls.
:-)
References:
- alt.linux.kiev.ua/packager/mike/srpms
скажем, pdksh — один из любимых пакетов, которые на мне значатся
— *вообще* не просил каши с тех пор, как был поправлен по мелкой
технически-формальной причине
PS: не собирай рутом, козлёночком станешь
> а так ставить программы из исходников не пробовал? ./configure && make
> && make install && означает, что следующая команды выполнится, если
> успешно выполнилась предыдущая.
Это вообще скверный совет, поскольку подразумевает сборку
привилегированным пользователем.
Вот таких и получали насквозь, которые рутом запускали затрояненые
configure всяких сендмайлов и чей-там-ещё-проломали-ftp несколько лет
тому.
@ 16.10.2007 11:32
См. тж.
