- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
...
%install
%{__rm} -rf %{buildroot}
mkdir -m 755 -p %{buildroot}%{_datadir}/common-lisp/source/%{name}
for s in $(find -regex '.+\.\(lisp\|asd\|org\)$'); do
install -D -m 644 $s %{buildroot}%{_datadir}/common-lisp/source/%{name}
done;
mkdir -m 755 -p %{buildroot}/etc/common-lisp/source-registry.conf.d
for las_conf in $(ls %{buildroot}/etc/common-lisp/source-registry.conf.d | tail -n 1); do
for last in $(echo "${last_conf}" | grep -oP '^[0-9]+'); do
for cl_prefix in $(echo "${last}+1" | bc); do
echo '(:include "/usr/share/common-lisp/source/%{name}/")' > \
"%{buildroot}/etc/common-lisp/source-registry.conf.d/${cl_prefix}-%{name}.conf"
install -m 644 ${cl_prefix}-%{name}.conf %{buildroot}/etc/common-lisp/source-registry.conf.d
done;
done;
done;
%files
%defattr(-,root,root,-)
%{_datadir}/common-lisp/source/%{name}/*
...
Dummy00001 30.09.2014 22:08 # 0
шелл как шелл. просто кто-то очень очень сильно извратился в строках 9-11.
ЗЫ строки 12-14 пахнут. install в 14й перепишет тот файл который echo в 12-13 создает.
> Менеджер пакетов завдующий установкой ПО написан на Питоне, но нельзя просто так взять и на Питоне же написать установочный скрипт.
Почему нет? Пишешь питон скрипт, включаешь его в пакет, вызываешь его во время инсталяции, а потом удаляешь. Или там какой извратный chroot используется во время инсталяции?
wvxvw 30.09.2014 22:30 # +1
Тут главная фишка в том, что в .spec файле переменную не объявить. Т.е. эти циклы не нужны (каждый цикл выполняется ровно один раз).
Да понятно, что можно написать инсталятор отдельно и включить его в... другой (убогий) инсталятор. Зачем они его придумали? Питон же уже был. А даже если и нет, то Перл точно был.
Почему шелл плох для этого? Куча бойлерплейта. Вот то, что я запостил - инсталяция одного пакета, а мне для полного счастья нужно около десятка. И они все будут выглядеть на 90% одинаковыми (потому что нет модульности, структур и интерфейсов).
Dummy00001 30.09.2014 23:15 # +2
а зачем тебе переменная на уровне spec файла то сдалась?
то что сверху это всего лишь template скрипта, где %{} заменятся на значения, и результат будет скормлен шелу. почти тот же самый принцип что и в GNU make.
другими словами, пишешь например, `R="%{buildroot}";` и дальше можешь пользоватся `$R` вместо `%{buildroot}`.
> Почему шелл плох для этого? Куча бойлерплейта.
признайся самому себе: ты просто не знаешь шела.
то что написано сверху (нахождение номера последнего пакета + 1) делается весьма прямолинейно и без извратов. например:
зы еще пахнет то что если предварительно ничего не было установлено, то ничего в /etc/common-lisp/source-registry.conf.d/ и не будет скопировано. плюс, я уверен что номера как минимум двухзначные с ведущими нулями.
но от этого говно не станет меньше. потому что поочередно инсталируя/деинтсталируя пару пакетов в разном порядке (что может случится, например, в случае апгрейда) можно счётчик до бесконечности накручивать. это первый раз когда я вижу что используются нефиксированые числа при инсталяции в .d каталог.
> И они все будут выглядеть на 90% одинаковыми
ну блин, тебе даже же %{name} предоставляют. чего тебе еще не хватает что бы из сделать 100% одинаковыми?
ЗЫ к слову. я тут чисто про шелл говорю - спеки ни разу не писал.
ЗЗЫ а вот это - find -regex '.+\.\(lisp\|asd\|org\)$' - по человечески пишется find -name '*.list' -o -name '*.asd' -o -name '*.org'. (регулярка скипает имена состоящие только из расширений - если это так и задумывалось, то добавь '?' перед '*'.)
wvxvw 30.09.2014 23:46 # 0
О, а в Мейкфале тоже просто так нельзя взять и объявить переменную.
> Без извратов.
Без извратов это так:
никто не сказал, что это весь скрипт, /etc/common-lisp/source-registry.conf.d/ создается где-то раньше.
Что мне не хватает?
Открой как-нибудь SCons файл и сравни количество текста.
В spec файле дохрена насторек которые можно было бы заполнить по-умолчанию.
Название пакета - почему бы не взять название папки в которой сорцы находятся? в 99% случаев это и будет название пакета. Сорцы - ровно точно так же: название папки + tar.gz. Описание? Почему бы не посмотреть в ту же папку и не прочитать его из файла README?
А как думаешь, в каком файле окажется %changelog?
Более того, если бы это был нормальный язык, можно было бы, например, унаследовать класс один раз от стандартного шаблона, переопределить в нем пару методов и использовать этот новый класс для однотипных задач для которых он был сделан. Тут же я вынужден копипастить бесполезную херню типа %prep %build и т.д.
Ну вот например, хочу я, чтобы ченжлог генерировался из логов Гита? Почему бы и нет, ну правда ж в 21-м веке живем все-таки. И хочу я это для всех проектов. И что мне остается? - правильно, либо написать инсталятор на другом языке и вызывать его из RPM скрипта (нафиг тогда нужен RPM скрипт?), либо паста в RPM скрипте.
Да, у меня есть папка .org в проекте, там локальные настройки Org-mode хранятся.
Dummy00001 01.10.2014 00:12 # 0
Я видел SCons'ы (и до этого перловы Cons'ы) из продакшн проектов. Текста там было наааамного больше. :)
> Более того, если бы это был нормальный язык
Ты зациклился на каком-то оverdesign'е. Как я и говорю, то чего тебе не хватает это простое знание шелла.
В сети валяется в хтмл "Unix Power Tools". Книга типа "cookbook" и содержит много разных примеров как чего можно делать с помощью шелли и базовых утилит. (случайно нагуглил: http://bioinfo2.ugr.es/OReillyReferenceLibrary/unix/upt/index.htm - програмирование на шелле: http://bioinfo2.ugr.es/OReillyReferenceLibrary/unix/upt/part08.htm )
> Более того, если бы это был нормальный язык [...]
Нафиг не нужно потому что как правило в пост-инстале обрабатываются только какие-то исключения.
Да и переплюнуть шелл по работе с файлами и текстом - в батч режиме - весьма сложно. Нужно только уметь.
В конце концов, написать кучу говна можно на любом языке. Но это не становится виной языка.
wvxvw 01.10.2014 08:16 # +2
И все. И это описывает и сборку и как удалить стартые результаты сборки, интерфейс командной строки и т.д.
Можно ли сделать на Шелле? - да. Нужно ли? - это совсем другой вопрос. Примеры Шелла, а особено подражания, где это доведено до абсурда, Автомейк, язык матрешка: макросы на одном языке раскрываются в макросы на другом языке (последовательным вызовом 5-6 разных програм!), а потом оказывается что если раскрыть макросы на третьем языке то из них получится 100500 разных недоязыков специальных для каждой команды этого языка. Более того, они сгенерируют 99% кода который у меня уже был, вот ну совсем рядом в соседней папке.
Например, для использования sed не достаточно знать регулярные выражения и Шелл, нужно знать мини-язык, которым sed описывает операции которые он может сделать. И так практически с каждой коммандой. find - аналогично, printf - то же самое, и т.д. Т.е. для того, чтобы понять программу на Питоне - достаточно знать Питон (т.е. каких-то 10-20 ключевых слов и столько же встроеных функций, остальное можно понять из комбинаций предыдущего). С Шеллом так не получится, потому что каждая команда использует свой алфавит и свои правила. Это не экономно с точки зрения того, какой выразительной силой должен обладать язык для того, чтобы описать необходимые операции.
roman-kashitsyn 01.10.2014 09:34 # +2
Java()
Тривиальные проекты на яве никому не нужны. Нужно управление зависимостями, подключение сторонних репозиториев пакетов, минимизация жарников, гибридная Scala/Java - компиляция, накатывания миграций на базы, тыщи действий, которые наполнят живые SCons файлы сотнями строк.
Dummy00001 01.10.2014 00:19 # +1
позвольте мне это переписать еще раз на шелле:
;)
wvxvw 01.10.2014 08:02 # 0
actionless 01.10.2014 13:59 # 0
а кому-то:
kegdan 01.10.2014 14:32 # 0
wvxvw 30.09.2014 23:53 # 0
Т.е. кто-то должен быть в системе и следить за базой данных, какие пакеты установлены, что делать если один и тот же пакет пытается установиться, не почистив предыдущую установку и т.п. Разбираться с такими нюансами из установочного скрипта - буэ. Но другого нет.
roman-kashitsyn 01.10.2014 09:19 # +1
Вызывать во время инсталляции пакета скрипт, который находится в пакете, который устанавливаем? Проблема курицы и яйца. Вероятно, есть некоторая ошибка в терминологии, но идея верна.
%install - фаза, на которой происходит инсталляция собранных бинарников в DESTDIR, выполняется он в корне проекта, подлежащего упаковке. Поэтому дёргать из него можно всё что угодно. Теже питоны, лишь бы они были в BuildRequires. Обычно там тупой (с)make install или вызов вашего любимой системы сборки для инсталляции.
roman-kashitsyn 01.10.2014 09:09 # 0
Вот до чего же люди плохо мыслят в четырёх измерениях. Пакетный менеджер rpm написан на сишке. Управление зависимостями с пистоном появились не сразу. А переделывать всю инфраструктуру, чтобы писать скрипты на питоне - идея так себе.
Кроме того, типичные скрипты для инсталляции выглядят одинаково паршиво и требуют много бойлерплейта на любом языке. Особенно при сборке сишного софта.
wvxvw 01.10.2014 09:22 # 0
Вообще, и Питон не нужен для этого. Изначально, когда GNU только задумывался, языком расширений должна была стать Схема (Guile). И вобщем, они к этому и идут, только очень медлено. То, что ЮНИКС решили реализовывать, по крайней мере в этом смысле, было ошибкой. Тогда, это конечно дало возможность использовать готовые програмы, но врезультате получилось то, чего и боялись (тогда от Tcl) - непродуманый беспомощный язык расширений + зоопарк замен этому языку.
roman-kashitsyn 01.10.2014 09:29 # 0
roman-kashitsyn 01.10.2014 10:54 # +1
Из исходников, как правило, собирается больше одного пакета. Шареные либы, платфомо-независимые данные, основные сервисы, утилиты, дебажные символы, devel-пакеты с публичными хедерами и библиотеками без soname, emacsen-пакеты, плагины для вима, очень много всего.
Более того, это даже не отношение один ко многим, скорее многие ко многим. Для сборки тулов LLVM нужно сразу несколько архивов с исходным кодом.
Да, логично упростить для простых пакетов. В дебиане для этого есть тула dh_make. C rpm я работал недолго, может, и там что-то такое есть.
Но для грамотной упаковки изучать инфраструктуру пакетирования всё равно придётся, и подстановка пары имён - меньшее из всех зол.
И что ещё важно понимать - в опенсорсе люди, которые собирают пакеты, как правило, не те же люди, что пишут софт. У них есть доступ в основном к релизным архивам с исходниками. Версии пакетов лишь отчасти связаны с версиями софта - пакеты могут накатывать собственные патчи на софт из архива в процессе сборки. Отсюда растут многие неудобства, возникающие при попытке упаковывать софт, который сам же и пишешь.
У нас, например, метаданные пакетов версионируются в отдельном git-репозитории, и changelog пакетов генерится из git log в этом репозитории.
wvxvw 01.10.2014 17:04 # 0
В Дебиане те же яйца только в профиль. Нужно менять подход, а не придумавать дополнительные инструменты, которые могут нагенерировать нового бойлерпейта, т.как с каждым таким инструметном количество бойлерплейта только увеличивается.
В чем принципиальное отличие SCons от Make? - Не в том, что единичный тривиальный билд будет меньше, а в том, что если у меня есть одинаковые сколько угодно сложные билды, написав на SCons билд один раз, я этот билд проинсталирую в системе, и все остальные билды смогут использовать его (внимание, никакого бойлерплейта! используется тот же код), или смогут импортировать часть! другого уже готового билда. Будь это Ява, Ц++, да что угодно, я смогу общий код из разных билдов использовать повторно, не копируя его!
roman-kashitsyn 01.10.2014 17:10 # +1
Именно так у нас и сделано.
> В чем принципиальное отличие SCons от Make?
В том, что make есть практически на любой юникс-системе, не нужно трахаться с обратно несовместимыми версиями питона и можно рассчитывать, что твой софт будет стабильно собираться даже на кофеварке.
Это никак не опровергает тот факт, что autotools и прочие configure - лютое говнище, а пакетирование под линупс - костыли и шаманство.
wvxvw 01.10.2014 17:49 # 0
Куча готовых рецептов для Мейка - это называется замести под ковер, вместо того, чтобы решить проблему.
roman-kashitsyn 01.10.2014 18:08 # 0
Давно хочу написать свою систему сборки с ориентацией на сишкопроекты, с Lua в качестве языка описания задач, поддержкой герметичных билдов, быстрыми инкрементальными сборками и подключением зависимстей из гитхабика одной строчкой.
Dummy00001 01.10.2014 18:22 # 0
да как по мне простой тулзы не хватает, которая нативно рекурсивна и просто А в Б по заданому правилу транслирует (включая случаи когда не только А, но и Б есть набор файлов). (в мэйке педрилы так и не сделали определения правил независимым от А и Б.)
до сишко/этц проектов еще дорости надо.
все зацикливаются на высокоуровневых функциях (авто зависимости) в то время как база остается слабой.
вот даже то повсеместное инсталирование библиотек и хидеров (внутри большого проекта) никто толком отслеживать не умеет. (что бы зависимости продолжали работать.) Cons умел - но SCons вроде так и не перенял.
roman-kashitsyn 01.10.2014 23:04 # 0
Для себя довольствуюсь CMake + ninja. Инкрементальные сборки с ninja - это песня. Но я её ещё не ковырял.
Dummy00001 02.10.2014 00:41 # 0
идея правильная - но на неправильном языке. :)
Saehrimnir 26.10.2020 16:07 # 0
Desktop 14.09.2018 21:10 # 0
- мне нравится эта идея. Надо будет попробовать как-то