Debian объявляет об официальной поддержке DebSrc3.0

Намекает, что apt-rpm RIP:

http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/2009-September...

Туда ему и дорога, если честно.

>Какое всё-таки устаревшее говно dpkg & friends. В том же RPM патчи хранилиз раздельно чуть ли не с самой первой версии ~15 лет назад.

Как уже было отмечено, в Debian тоже патчи хранятся отдельно в debian/patches/*, но хочется ещё раз подчеркнуть толщину троллинга.

А что, у дебианщиков уже есть аналог delta-rpm?

>А что, у дебианщиков уже есть аналог delta-rpm?

Ага. debdelta называется. С разморозкой.

>Вот мы вводим команду ls, она выводит содержимое каталога - да, как великолепно, в других ОС этого нет, это - тот самый хай-тех, про который везде говорят, как нам повезло, что у нас линукс

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

То ли дело:
ls | lp
или
ls | mail -s "List of files" box@mailserver.com

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

Правда? А почему тогда при apt-get update ко мне все еще приезжают полные копии пакетов, а когда делаю zypper update, то дельты и патчи? ЧЯДНТ?

> Формат пакета deb как раз самый простой и правильный: control.tar.gz + data.tar.(gz|bz2|lzma), упакованные в ar-архив.
А не кажется ли вам, что формат txz в Slackware более простой? Насчет правильности — спорно, конечно, но простота рулит. Проще может быть разве что pkg.tar.gz из CRUX-а

> То ли дело:
> ls | lp
dir > prn было ещё в MS-DOS. Так-то!
Конечно в винде консоль убогая, но не настолько, как об этом думают некоторые линуксоиды.

> Пожимая плечами - ну, в общем, ничем не хуже rpm -i somepackage.src.rpm :) Даже лучше - всё в текущем каталоге, бери и собирайся :)

давно не смотрел как в федоре, а в мандриве эта команда распаковывает .src.rpm в ~/rpmbuild, а это даже лучше чем текущий каталог.

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

>dir > prn было ещё в MS-DOS. Так-то!

Не напомнить по чьему лекалу и с примесью чего был сделан MS-DOS (а именно - практически точная копия CP/M в версии 1.0 + крошечный закос под Unix начиная с версии 2.0) и какое отношение он имеет к современной Windows (MS-DOS нынче не является частью Windows)? Поэтому MS-DOS от хай-тека далёк даже больше, чем Windows.

>> Какое всё-таки устаревшее говно dpkg & friends. В том же RPM патчи хранилиз раздельно чуть ли не с самой первой версии ~15 лет назад.

Как уже было отмечено, в Debian тоже патчи хранятся отдельно в debian/patches/*

То есть сабж не нужен?

но хочется ещё раз подчеркнуть толщину троллинга.

Это настолько же троллинг, насколько и опыт.

>> Как уже было отмечено, в Debian тоже патчи хранятся отдельно в debian/patches/*

>То есть сабж не нужен?

Сабж лишь создаёт удобства тем немногочисленным людям, которым нужно выдрать патчи из пакета-исходника, не распаковывая сам пакет. Не более. И это совершенно ничего не говорит о недоразвитости deb и "доразвитости" RPM.

>Это настолько же троллинг, насколько и опыт.

И это заметно по толщине следующего высказывания:

>Какое всё-таки устаревшее говно dpkg & friends. В том же RPM патчи хранилиз раздельно чуть ли не с самой первой версии ~15 лет назад.

> какое отношение он имеет к современной Windows

Вообще-то cmd.exe в современной виндоуз --- нативное приложение.

Правда, это немного странноватый шел, но он есть %)

> Намекает, что apt-rpm RIP:

Альтовцы расстроятся, наверное...

>Вообще-то cmd.exe в современной виндоуз --- нативное приложение.

>Правда, это немного странноватый шел, но он есть %)

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

им всё равно. их apt-rpm похож на оригинальный apt-rpm так же, как их rpm похож на оригинальный. то есть совсем не похож например.

> Альтовцы расстроятся, наверное...

Ы-ы-ы, у них/у нас там уже не вполне RPM, будет не вполне APT, ничего, привыкнут/привыкнем :)

> им всё равно. их apt-rpm похож на оригинальный apt-rpm так же, как их rpm похож на оригинальный. то есть совсем не похож например.

Ну, вообще, lorg2 + патчи. lorg3 уже так просто не всосать, из-за зависимости последнего на API librpm-4.4+.

Уже, кстати, 139 пакетов перевели.

Не, не расстроятся. У них, как у настоящих Русских программистов, apt-rpm давным давно с апстримом не имеет ничего общего.

>> Это в идеально-сферическом случае и строго прямых руках писавшего спеку. А ставя где-то подобраный пакет на это можно только надеяться )

так всегда

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

так нужно.

Тоже не понял. Конечно так нужно, писать спеку максимально портабельно. Но реальность-то другое дело.

зря. не нужно этого делать.

Об этом тут уже подискутировали, имхо, единственный минус в том, что невыполнение этой операции может оборвать и установку. В остальном — если в 85% случаев вбокс будет запущен если не сразу, то на этом же ядре и т.п., этого, думаю, достаточно. А если нет — в лишней перекомпиляции ничего страшного, сами говорите ;)

не может

Значит для вас не может. А кому поставить, и чтобы оно работало с минимумом доп. телодвижений (обычные десктопные задачи, никакой не сервак) — там может. Это даже в случае если юзер отлично знает и как всё, что нужно руками сделать. А если не знает, заставлять его разбираться и докручивать установку >1000 пакетов стандартной системы — это, имхо, достаточно жестоко ;)

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

Так это ж был только список файлов в .src.rpm. А это всё конечно есть, в спеке:

[code]Patch0: polipo-makefile.patch Patch1: polipo-allowHttpUnknown.patch [..] %prep %setup -n polipo-%{version} %patch0 -p1 -b .makefile %patch1 -p1 -b .allowHttpUnknown[/code]

За корректность не ручаюсь, но это там таки есть.

Сорри, форматирование

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

Так это ж был только список файлов в .src.rpm. А это всё конечно есть, в спеке:

Patch0: polipo-makefile.patch
Patch1: polipo-allowHttpUnknown.patch
[..]
%prep %setup -n polipo-%{version}
%patch0 -p1 -b .makefile
%patch1 -p1 -b .allowHttpUnknown

За корректность не ручаюсь, но это там таки есть.

>Сабж лишь создаёт удобства тем немногочисленным людям, которым нужно выдрать патчи из пакета-исходника, не распаковывая сам пакет. Не более. И это совершенно ничего не говорит о недоразвитости deb и «доразвитости» RPM.

Справедливости ради надо отметить, что использование debian/patches сейчас не является обязательным. Полно пакетов, в которых нет debian/patches, и где сопровождающие вносили изменения не через патчи, а потом генерировали diff.gz. И еще отличие в том, что сейчас процедура patch/unpatch для quilt/dpatch/dbs нужно руками прописывать в rules. Теперь же планируется, что при сборке патчи будут накладываться автоматически без танцев вокруг rules. При этом quilt в build depends указывать уже будет не нужно.

> Пацаны, не делайте мне смешно. Я в своё время на базе bsdmake одну прикладную системку сборки настряпал, должен вам доложить, там внутри BSD'шных .mk'шек такие перлы встречались, что ого-го :) В итоге пришлось и bsdmake подхачить, и фряшного набора .mk'шек отказаться :)

Смотря с чем сравнивать же ;) Там было емнип собрать для себя софтину pkgbuild'ом, или осиливать для этого сборку rpm, при одинаковом качестве, в смысле количестве потенциальных проблем.

>Так это ж был только список файлов в .src.rpm. А это всё конечно есть, в спеке:

Вопрос: а в SRPM патчи — это единственно установленный способ внесения изменений в исходники или нет? Если я сделаюправку в исходных текстах upstream, без использования какого-то упорядоченного набора патчей, то мне просто сгенерируется один такой большой патч (большой такой diff), в котором будут все отличия от upstream?

> Правда, я давно уже не разглядывал rpm-дистрибутивы, отличные от AltLinux, поэтому не уверен, везде ли внедрён этот механизм (в Альте он появился сравнительно недавно).

Не оно? http://rpm.org/api/4.4.2.2/triggers.html

> Вопрос: а в SRPM патчи — это единственно установленный способ внесения изменений в исходники или нет? Если я сделаюправку в исходных текстах upstream, без использования какого-то упорядоченного набора патчей, то мне просто сгенерируется один такой большой патч (большой такой diff), в котором будут все отличия от upstream?

Если что, я тот анонимус, который полдня один пакет собирал, и пока всё, так что много не подскажу ) Но в смысле, зачем сгенерируется патч? Поправите исходники, положите их такими в srpm и всё. Проблемы, как я понимаю, будут только у тех, кому захочется взглянуть на модификации исходника — им надо будет самим искать и diff'ать оригинал, вместо того чтобы просто взять отдельные патчи из srpm.

>Всегда что? Спек написан идеально, с использованием исключительно переменных для всех путей? )

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

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

Во первых, это не единственный минус, как минимум, еще проявляются безумные зависимости на связку gcc (что отчасти ладно) и kernel-devel, что вообще недопустимо ибо новый kernel-devel может вытащить новое ядро, а новое ядро новый тулчайн и в итоге вообще возможно ничего работать не будет)

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

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

В остальном — если в 85% случаев вбокс будет запущен если не сразу, то на этом же ядре и т.п., этого, думаю, достаточно. А если нет — в лишней перекомпиляции ничего страшного, сами говорите ;)

собственно, все.

>Пожимая плечами - ну, в общем, ничем не хуже rpm -i somepackage.src.rpm :) Даже лучше - всё в текущем каталоге, бери и собирайся :)

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

Нет, ну зачем патч сгенерируется, я понимаю. Перефразирую вопрос: хранение оригинальных исходников из upstream внутри SRPM обязательно или нет? То есть могу ли я не использовать внутри SRPM схему orig+diff (или orig+set_of_patches), а сразу положить туда уже *исправленные* исходники без orig? Я к тому, что в Debian схема orig+diff установлена, как единственная. Сейчас только речь идет о том, в каком виде этот diff поставлять.

Если я сделаюправку в исходных текстах upstream, без использования какого-то упорядоченного набора патчей, то мне просто сгенерируется один такой большой патч (большой такой diff), в котором будут все отличия от upstream?

Вопрос не совсем понятен. Сам по себе RPM никаких diff'ов не делает, ни больших, ни маленьких. Сделать с upstream'ными (aka ванильными) исходниками перед упаковкой их в .src.rpm (посредством прописывания в Source0, Source1 и т. д.) можно все, что угодно, в принципе. Другое дело, что, к примеру, Fedora Packaging Guidelines модификацию ванильных исходников крайне не рекомендуют. Можно пример — что есть и чего хочется?

> Нет, ну зачем патч сгенерируется, я понимаю.

Это просто я не понял )

То есть могу ли я не использовать внутри SRPM схему orig+diff (или orig+set_of_patches), а сразу положить туда уже *исправленные* исходники без orig? Я к тому, что в Debian схема orig+diff установлена, как единственная. Сейчас только речь идет о том, в каком виде этот diff поставлять.

Да вроде бы вполне. Пробовать влом, но препятствий в голову не приходит. А как вообще в дебиане система сборки понимает, оригинальный вы ей исходник даете, или модифицированный? Другое дело рекомендации, как тут уже сказали, но это просто для удобства же.

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

собственно, как и в дебиане, это не технический вопрос, а вопрос политики сборки пакетов.

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

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

а насчет RPM: RPM'у до deb еще много лет развиваться:

* debconf

* зависимости

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

Звукорежисёр на работе делал скриншоты)

> * debconf

интерактивные post-install скрипты не нужны

* зависимости

это вопрос не к RPM

debconf

Что это такое?

зависимости

У RPM нету зависимостей? 8-0

> интерактивные post-install скрипты не нужны

поэтому RPM-based дистрибутивы и являются таким отстоем: поставил пакет и сиди с нуля настраивай/доделывай/юзеров добавляй/кеши генерируй/ключи итп

это вопрос не к RPM

именно к нему

ipconfig /all > net.txt
rute print >> net.txt
copy net.txt prn

На русской Windows до XP включительно (насчет более поздних не уверен) половина текста в net.txt будет кракозяблами.

NB: оффтопить так оффтопить :)

>А как вообще в дебиане система сборки понимает, оригинальный вы ей исходник даете, или модифицированный? Другое дело рекомендации, как тут уже сказали, но это просто для удобства же.

Понятное дело, что всегда можно обмануть Debian, подсунув ему подправленный исходник, а потом сгенерировав еще какой-то diff после, но это обман себя самого. :)

Исходники из upstream в Debian сначала пакуются в orig.tar.gz. А на распакованных исходниках уже осуществляется правка различными способами: либо сразу в коде, либо через систему патчей. А потом из этих изменений при сборке dpkg-source генерирует diff.gz, который вычисляется относительно orig.tar.gz (лежит рядом в директории). Таким образом образуется связка orig+diff, которая и льется в репозиторий исходников.

Сейчас же вместо большого diff будет как бы отдельно хранение Debian-спека (/debian) и патчей с описаниями в одном тарболе (но не в одном diff!)

поэтому RPM-based дистрибутивы и являются таким отстоем: поставил пакет и сиди с нуля настраивай/доделывай/юзеров добавляй/кеши генерируй/ключи итп

Чушь и 4.2. К примеру,

$ rpm -q --scripts openssh-server
preinstall scriptlet (using /bin/sh):
/usr/sbin/useradd -c "Privilege-separated SSH" -u 74 \
	-s /sbin/nologin -r -d /var/empty/sshd sshd 2> /dev/null || :
postinstall scriptlet (using /bin/sh):
/sbin/chkconfig --add sshd
preuninstall scriptlet (using /bin/sh):
if [ "$1" = 0 ]
then
	/sbin/service sshd stop > /dev/null 2>&1 || :
	/sbin/chkconfig --del sshd
fi
postuninstall scriptlet (using /bin/sh):
/sbin/service sshd condrestart > /dev/null 2>&1 || :

> А это всё конечно есть, в спеке

Да, разумеется есть :) но, согласитесь, не так наглядно :)

> поставил пакет и сиди с нуля настраивай/доделывай/юзеров добавляй/кеши генерируй/ключи итп

Конкретика где? Ключи генерируются при первом старте сервиса.

именно к нему

?

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

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

Во первых, это не единственный минус, как минимум, еще проявляются безумные зависимости на связку gcc (что отчасти ладно) и kernel-devel, что вообще недопустимо ибо новый kernel-devel может вытащить новое ядро, а новое ядро новый тулчайн и в итоге вообще возможно ничего работать не будет)

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

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

Можно ли называть обслуживанием то, что однозначно требуется выполнить для запуска программы? Тогда много чего в установке есть обслуживание. А копирование манов вообще непонятно зачем, пусть отдельным пакетом тянут кому надо ;)

написать он их действительно безбажно не смог

Безбажно это как? Обеспечить сборку модуля даже на несовместимом с кодом программы gcc? Или что тут можно назвать именно багом по вине сборщика?

> Если я сделаюправку в исходных текстах upstream, без использования какого-то упорядоченного набора патчей, то мне просто сгенерируется один такой большой патч (большой такой diff), в котором будут все отличия от upstream?

Строго говоря, если Вы просто поправите в апстримных исходниках какой-то код, а потом просто завернёте полученное в качестве .tar.gz, rpm не будет Вам мешать. Но так делать /не принято/, это, натурально, моветон.

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

> Чушь и 4.2. К примеру

в неинтерактивном скрипте невозможно учесть все случаи. и получаются идиотизмы вроде того что имеем две fido-шные программы, одна создает группу ftn, а другая группу fido.

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

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

Генерация host-ключей при первом запуске предусмотрена в init-скрипте

костыль которым попытались решить проблемы пакетного менеджера

> http://rpm.org/api/4.4.2.2/triggers.html

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