Обновление Pacman в Arch Linux

> Арч, кстати, тоже можно перевести на deb/rpm.

Самая гениальная мысль во всём треде про pacman. :)

Ну а в самом деле пофигу. У них паритет по фичам. Настолько, что ни дебианотролли, ни арчетролли не смогли найти разницы.

Да какая разница, как и что делают скрипты в пакете формата, которого не должно существовать?

Я вот не хочу, чтобы успешно работающая вещь «сдохла», ради туманных обещаний «сделать зашибись» (непонятно как). И почему-то абсолютно уверен что будет именно так, как я хочу ;)

Правильно я понимаю, что ничего конкретно по вопросу ответить не сумеете?

На базовую систему нужно.

Ну, если ты о самом-самом фундаменте, то да, наверняка. Но и там должна, мне кажется, царить максимальная ванильность.

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

Петины пакеты можно было бы маркировать как libololo-1.2.3_petya.pkg. И тогда пусть, на здоровье, свинячит ими куда хочет. Тут самое сложное - разрулить конфликты между libololo-1.2.3_author.pkg и libololo-1.2.3_petya.pkg, включая зависимый софт. Но вроде решаемо и это.

И тогда (эротическая фантазия to follow):

softmanager install megasoftina
... searching megasoftina...
megasoftina modifications: native, petya, kolya, shkololo (1, 2, 3, 4)2

... petya-contributed megasoft build selected, resolving dependencies...
next packages will be replaced:
libololo-stable_native by libololo-stable_petya
bugoga-stable_native by bugoga-stable_petya

Там грабли еще будут, если что-то в системе уже зависит от bugoga_stable_native, но извернуться можно.

а чё известно когда оффрепы с дельтами появяца? или в планах нету у них?

И почему-то абсолютно уверен что будет именно так, как я хочу ;)

А чего можно хотеть от пакета? Я вот хочу ровно одного: чтобы он ставил софт куда надо и рулил зависимости/конфликты.

Так это везде есть и работает.

Правильно я понимаю, что ничего конкретно по вопросу ответить не сумеете?

Ясен хрен, не сумею, пока ты не задашь мне этот самый вопрос. Риторических не надо.

Ты выделенную жирным надпись «Если бы пакеты имели одинаковый формат.» хорошо видишь, нет?

Ну, у suse и rhel одинаковый формат, и? Вы как-то совсем уж оторваны от реальности :)

Только когда патчи затрагивают API библиотек.

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

Там грабли еще будут, если что-то в системе уже зависит от bugoga_stable_native, но извернуться можно.

Ну так bugoga-stable_petya provides=('bugoga-stable_native') , и всё нормально. (А если не provides, то забанить bugoga-stable_petya, пусть Петя не придуривается.)

прошу прощения, действительно попутал с geekless. Вопрос (про скрипты) был здесь.

А чего можно хотеть от пакета? Я вот хочу ровно одного: чтобы он ставил софт куда надо и рулил зависимости/конфликты.

Я еще хочу, чтобы он ставил так как надо. Чтобы при обновлении сервера в стабильном релизе я вообще мог спать спокойно. А при обновлении до нового стабильного релиза - мне достаточно было бы просто прочитать Release Notes.

Так это везде есть и работает.

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

Разве ценой размазывания низведения качества хороших дистрибутивов о обычного уровня (плинтуса и ниже).

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

Типичный пример «специфичного для дистрибутива патча, который не взяли в апстрим» — это патчинг в дебиане конфигов (а иногда и сорцов) ПО, чтобы по дефолту они пытались использовать дебиановские симлинки а ля «просто браузер», «просто терминал» и т.п. Вопрос с конфигами элементарно решается хуком. А патчить сорцы ради такой ерунды — вообще нехрен.

Ну, у suse и rhel одинаковый формат, и? Вы как-то совсем уж оторваны от реальности :)

1. Для огромного количства ПО «установка» — это «распаковать в корень и добавить запись о пакете в базу данных». Будет ли пакет работать после этого на чужой системе — отдельный вопрос.

2. Что касается хуков, postinst-скриптов и прочей обвязки, то их и надо если не стандлартизировать, то хотя бы сделать так, чтобы они не мешали друг другу для разных систем.

Всё ещё дрочишь на циферки?

Именно так.

Обман. Пока не обновишь pacman, ничего другое не будет обновляться.

Я неудачно выразился. Действительно, во время первого pacman -Syu обновился только pacman, а во время второго он пожаловался на filesystem. Проблема в том, что новый pacman сдох от pacman -S --force filesystem, заменив при этом /etc/mtab на пустой файл и сам же от этого огорчившись.

А, ты смотришь именно со стороны вопроса «как взгромоздить один формат на существующие системы», если я правильно понял.
То есть вопроса, по сути, три: 1. как отрабатывать дистроспецифичные скрипты в пакетах? 2. как поступать в случая потребности установить софт с не-ванильными патчами? и 3. черт, меня отвлекли и я потерял мысль, а думать ее заново мне лень.

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

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

Чтобы при обновлении сервера в стабильном релизе я вообще мог спать спокойно.

Это головная боль ав-то-ра софта. Система должна предоставить автору FHS, рантайм для скриптов автоматизаци и формат структуры пакета, плюс список версий «стабильной» и прочих ветвей софта, с которыми он должен собирать свое поделие. Всё остальное - работа автора. А ты будешь спать спокойно, потому что пацаны, оторые пишут, например, Томкат, лучше знают, как он ему нужно обновляться.

Кроме того, сборка пакета автором исключает, например, такой развесистый дебилизм, как /etc/httpd/хрен_знает_что в одних системах и /etc/apache2/нет_всё_иначе в других.

Поэтому «разные дистры» нужно убить.

И зачем тогда нужен этот ваш арч?

man сарказм. Вы же дебианщик, должны были сразу в маны полезть.

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

А где был разговор про помойку пакетов? Репозитории на этом этапе не затрагиваются вообще.

Главное, зачем? Мейнтейнеры никуда не денутся. Только на один пакет их потребуется тридевять, по числу дистрибутивов.

Именно столько, сколько требуется уже сейчас. Неужели вы не понимаете, что нельзя сделать один универсальный дистрибутив. Дистрибутив - это не ванильные исходники, это определённые патчи и специфические расширения. Именно поэтому существуют цепочки вроде Debian -> Ubuntu -> Mint. Даже если все рано или поздно придут к одному формату, всё равно найдутся те, кто захочет всё сделать по своему. В той же венде есть InstallShield, Wise, Inno Setup и прочие сущности со своими особенностями, при том, что казалось бы, всё сводится к банальным .exe и .msi.

никто не согласится же

Да с тим никто и не спорит. Это ж так, мечты.

да ну нафиг, пичалька одна

В качестве небольшой иллюстрации.

У меня в системе

$ ls /var/lib/pacman/local/* | wc -l
4540

Из них, только

$ ls /var/lib/pacman/local/*/install | wc -l
254

Давайте посмотрим, что ж это за хуки. Львиная доля хуков касается, банально, обновления кэша иконок:

$ grep gtk-update-icon-cache  -l /var/lib/pacman/local/*/install | wc -l
41
$ grep xdg-icon-resource -l /var/lib/pacman/local/*/install | wc -l
16

Другие обновляют кэш шрифтов:

$ grep 'fc-cache'  -l /var/lib/pacman/local/*/install | wc -l
17

Некоторые просто сообщают полезную информацию:

$ grep 'cat <<' -l /var/lib/pacman/local/*/install | wc -l
17
$ grep 'cat <<' /var/lib/pacman/local/*/install -A2
/var/lib/pacman/local/antiword-0.37-3/install:  cat << EOF
/var/lib/pacman/local/antiword-0.37-3/install-NOTES On Antiword Integration:
/var/lib/pacman/local/antiword-0.37-3/install-
--
/var/lib/pacman/local/avahi-0.6.30-6/install:  cat <<EOF
/var/lib/pacman/local/avahi-0.6.30-6/install-==> The following daemons may be added to DAEMONS in /etc/rc.conf:
/var/lib/pacman/local/avahi-0.6.30-6/install-==> avahi-daemon: the mdns responder, you probably want this.
--
/var/lib/pacman/local/catfish-0.3.2-4/install:  cat << EOF
/var/lib/pacman/local/catfish-0.3.2-4/install-    Install at least one of the following search backends for catfish:
/var/lib/pacman/local/catfish-0.3.2-4/install-      'findutils', 'slocate', 'tracker', 'beagle', 'strigi' or 'pinot'
--
/var/lib/pacman/local/derpity-gtk-theme-20110522-1/install:  cat <<EOF
/var/lib/pacman/local/derpity-gtk-theme-20110522-1/install-Set for:
/var/lib/pacman/local/derpity-gtk-theme-20110522-1/install-  Gtk2: \`gtk-theme-name="Derpity"' in:
--
/var/lib/pacman/local/fontconfig-2.8.0-1/install:  cat << _EOF
/var/lib/pacman/local/fontconfig-2.8.0-1/install-
/var/lib/pacman/local/fontconfig-2.8.0-1/install-===> Important Fontconfig configuration change <===
--
/var/lib/pacman/local/fuse-2.8.6-1/install:  cat << 'EOM'
/var/lib/pacman/local/fuse-2.8.6-1/install-==> You must load the fuse kernel module to use FUSE.
/var/lib/pacman/local/fuse-2.8.6-1/install- -> Run 'modprobe fuse' to load the module now.
--
/var/lib/pacman/local/fusion-icon-20101021-1/install:  cat << EOF
/var/lib/pacman/local/fusion-icon-20101021-1/install-==> Updating icon cache.....
/var/lib/pacman/local/fusion-icon-20101021-1/install-EOF
--
/var/lib/pacman/local/fusion-icon-20101021-1/install:  cat << EOF
/var/lib/pacman/local/fusion-icon-20101021-1/install-==> Updating icon cache.....
/var/lib/pacman/local/fusion-icon-20101021-1/install-EOF
--
/var/lib/pacman/local/gnuplot-4.4.3-1/install:cat << EOF
/var/lib/pacman/local/gnuplot-4.4.3-1/install-==> To add the gnuplot mode in Emacs, add the content of /usr/share/emacs/site-lisp/dotemacs to your ~/.emacs file.
/var/lib/pacman/local/gnuplot-4.4.3-1/install-EOF
--
/var/lib/pacman/local/hplip-3.11.12-1/install:  cat << EOF
/var/lib/pacman/local/hplip-3.11.12-1/install-
/var/lib/pacman/local/hplip-3.11.12-1/install-NOTE
--
/var/lib/pacman/local/libgphoto2-2.4.11-1/install:  /bin/cat <<THEEND
/var/lib/pacman/local/libgphoto2-2.4.11-1/install-NOTE
/var/lib/pacman/local/libgphoto2-2.4.11-1/install-----
--
/var/lib/pacman/local/lxdm-git-20110907-1/install:cat << EOF
/var/lib/pacman/local/lxdm-git-20110907-1/install-
/var/lib/pacman/local/lxdm-git-20110907-1/install-	>>> Substitute your old /etc/lxdm/lxdm.conf
--
/var/lib/pacman/local/networkmanager-0.9.2.0-1/install:  (( $(vercmp 0.8.3 $2) > 0 )) && cat <<MSG
/var/lib/pacman/local/networkmanager-0.9.2.0-1/install-ATTENTION:
/var/lib/pacman/local/networkmanager-0.9.2.0-1/install-  /etc/NetworkManager/nm-system-settings.conf has been replaced
--
/var/lib/pacman/local/pulseaudio-1.1-2/install:  cat << MES
/var/lib/pacman/local/pulseaudio-1.1-2/install->>> See the wiki at http://wiki.archlinux.org/index.php/PulseAudio for details
/var/lib/pacman/local/pulseaudio-1.1-2/install-    on configuring your system for PulseAudio.
--
/var/lib/pacman/local/sane-1.0.22-4/install:	/bin/cat <<THEEND
/var/lib/pacman/local/sane-1.0.22-4/install-NOTE
/var/lib/pacman/local/sane-1.0.22-4/install-----
--
/var/lib/pacman/local/splix-2.0.0-10/install:  cat <<EOF
/var/lib/pacman/local/splix-2.0.0-10/install-Installation of the color profile for color printers:
/var/lib/pacman/local/splix-2.0.0-10/install------------------------------------------------------
--
/var/lib/pacman/local/xdm-archlinux-0.3-4/install:  cat << EOF
/var/lib/pacman/local/xdm-archlinux-0.3-4/install-
/var/lib/pacman/local/xdm-archlinux-0.3-4/install-  The Archlinux XDM theme was installed to /etc/X11/xdm/archlinux
--
/var/lib/pacman/local/xf86-video-nouveau-0.0.16_git20120106-1/install:   cat << _EOF
/var/lib/pacman/local/xf86-video-nouveau-0.0.16_git20120106-1/install-  ==> make sure you use KernelModeSetting (KMS)
/var/lib/pacman/local/xf86-video-nouveau-0.0.16_git20120106-1/install-  ==> see http://wiki.archlinux.org/index.php/Nouveau#KMS for more
--
/var/lib/pacman/local/xf86-video-nouveau-0.0.16_git20120106-1/install:    cat << _EOF
/var/lib/pacman/local/xf86-video-nouveau-0.0.16_git20120106-1/install-  ==> ATTENTION: Usermode support has been dropped
/var/lib/pacman/local/xf86-video-nouveau-0.0.16_git20120106-1/install-  ==> make sure you use KernelModeSetting (KMS)

Или вот, оболочка обновляет /etc/shells:

$ cat /var/lib/pacman/local/zsh-4.3.15-2/install
post_install() {
	grep -q '/bin/zsh' etc/shells || echo '/bin/zsh' >> etc/shells
}

post_upgrade() {
	post_install
}

pre_remove() {
	sed -i '/^\/bin\/zsh/d' etc/shells
}

Ну и так далее.

Большая часть этих действий вообще не требует скриптов как таковых. «Устанавливаемый пакет содержит файлы в /каталоге/для/иконок ? — Вызовем обновление кэша.» Это всё можно плагинами к пакетнику решать.

Типичный пример

Неа. «Типичный пример» - это вот: http://anonscm.debian.org/viewvc/pkg-apache/trunk/apache2/mpm-itk/

А то что вы привели как пример - элементарные случаи глупости апстрима.

А патчить сорцы ради такой ерунды — вообще нехрен.

Отнюдь. Я вот хочу качественный набор софта. И не хочу устанавливать тридевять консольных браузеров чтобы посмотреть, к примеру, вывод mod_status апача и отобразить html в mutt.

К сожалению, разработчиков подобные вещи могут и не заинтересовать. Потому патчи, увы.

1. Для огромного количства ПО «установка» — это «распаковать в корень и добавить запись о пакете в базу данных».

Мне не нужно это «огромное количество». Оно 1) не покрывает то множество, что мне нужно 2) в него не входят действительно важные пакеты.

2. Что касается хуков, postinst-скриптов и прочей обвязки, то их и надо если не стандлартизировать, то хотя бы сделать так, чтобы они не мешали друг другу для разных систем.

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

Pacman движется в сторону емержа? Арчеры делают свой велосипед?

Это головная боль ав-то-ра софта.

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

Поэтому он предоставляет интерфейсы: управление сборкой, ключи командной строки программы, файлы конфигурации.

Кроме того, сборка пакета автором исключает, например, такой развесистый дебилизм, как /etc/httpd/хрен_знает_что в одних системах и /etc/apache2/нет_всё_иначе в других.

Это не дебилизм. Вы не поверите, но в debian - это пример следования стандарту (Debian Policy). В другом дистрибутиве - может быть и иной стандарт. Либо вы сотрете абсолютно все различия между дистрибутивами - либо «дебилизмы» никуда не денутся.

Как сделать зашибись - вы знаете? Предложите, пожалуйста, конкретный вариант на примере этого самого апача. Только просьба предварительно заглянуть в /etc/httpd/ и /etc/apache2/ - и узнать хорошенько что там есть и как устроено.

LOLWUT? Тебя мама в детстве пугала мейнтейнерами пакетов из аура?

Ну вот начинается... делают из арча дебиан:(

«Типичный пример» - это вот: http://anonscm.debian.org/viewvc/pkg-apache/trunk/apache2/mpm-itk/

6 	apache2-mpm-itk (just mpm-itk for short) is an MPM (Multi-Processing
7 	Module) for the [1]Apache web server. mpm-itk allows you to run each of
8 	your vhost under a separate uid and gid -- in short, the scripts and
9 	configuration files for one vhost no longer have to be readable for all
10 	the other vhosts.

Это не «типичный пример». Это, по сути, отдельная версия программы. Накладывать эти патчи перед сборкой пакета в дебиан или перед сборкой под сюзю — никакой разницы. Эти не дистроспецифично. Так что мимо.

А то что вы привели как пример - элементарные случаи глупости апстрима.

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

Отнюдь. Я вот хочу качественный набор софта. И не хочу устанавливать тридевять консольных браузеров чтобы посмотреть, к примеру, вывод mod_status апача и отобразить html в mutt.

Если your-favorite-program-name имеет зашитую в сорцы команду вызова браузера, то это действительно глупость апстрима. Пишите багрепорт. Дистрибутив-то ни при чем. Временные заплатки, накладываемые мейнтейнером, чтобы исправить досаждающие баги ПО — это опять не «дистроспецифичные патчи». Это временные заплатки и есть.

К сожалению, разработчиков подобные вещи могут и не заинтересовать. Потому патчи, увы.

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

Мне не нужно это «огромное количество». Оно 1) не покрывает то множество, что мне нужно 2) в него не входят действительно важные пакеты.

Я намекаю вам на то, что проблема хуков вами «несколько» преувеличена. И что главная проблема — не в хуках. Алло.

Да что ты говоришь. Всего один раз использовал force: при установке с последнего CD.

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

Почему-то вендовый софт с чудовищно сложными инсталлерами, сделанными авторами, обновляется без проблем. С выбором компонент, с настройками и прочим. А в люниксе рассовать пару десятков файлА по каталогам и перезапустить службу-другую уже «ой, это очень сложно».

Либо вы сотрете абсолютно все различия между дистрибутивами

А и хотелось бы. Серьезно. Все эти «дистрибутивы» должны жить на уровне «kernel-3.2.0_patchset_debian.pkg» и еще пару таких же в общей репе как максимум. А в большинстве случаев на «дистрибутив» хватит трех пакетов - с иконками, с цветовыми схемами и с нескучными обоями.

Как сделать зашибись - вы знаете?

АВТОР ЗНАЕТ, сколько раз повторять. Если человеки пишут, например, сервер приложений, УЖ НАВЕРНОЕ эти человеки в состоянии авторитетно решить, где и как он должен хранить конфиги.

и узнать хорошенько что там есть и как устроено.

Да офигеть можно, какие чудовищные сложности, три каталога с конфигами и симлинками.

Помню как-то раз мне яндекс отдал 32-х битные пакеты вместо 64-х битных. Веселуха была.

яндекс

ССЗБ

А где был разговор про помойку пакетов? Репозитории на этом этапе не затрагиваются вообще.

Тогда я наверное вас не понял. Зачем нужна какая-то дополнительная прослойка - новый «менеджер», управляющий в общем-то несовместимыми форматами?

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

То что нельзя, я как раз таки понимаю. См. комментарии выше.

Даже если все рано или поздно придут к одному формату, всё равно найдутся те, кто захочет всё сделать по своему.

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

Все эти «дистрибутивы» должны жить на уровне «kernel-3.2.0_patchset_debian.pkg»

Вот-вот.

Имеют смысл в первую очередь фичи, а не _patchset_${distname}. Если мне нужна, скажем, базовая система с поддержкой selinux, я значит я и поставлю профиль/ветку с поддержкой selinux. И как при этом набор пакетов будет называться: *_patchset_vasya или *_patchset_petya — меня не волнует.

Пусть несовместимыми будут только те пакеты, которые _дейтсвительно_ несовместимы. А не те, которые нарушают чью-то там высосанную из пальца «политику дистрибутива».

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

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

А в люниксе рассовать пару десятков файлА по каталогам и перезапустить службу-другую уже «ой, это очень сложно».

Это еще не все. Нужно еще конфиги обновить. Здорово ведь будет, если вы запустите сервис со старым конфигом, а там возьми и найдись опция, которая больше не поддерживается.

АВТОР ЗНАЕТ, сколько раз повторять.

Сколько не повторяй, аргументов это не заменит.

... УЖ НАВЕРНОЕ

Улыбнуло...

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

Да офигеть можно, какие чудовищные сложности, три каталога с конфигами и симлинками.

Вот и объясните «как надо» (тм). Пацаны (apache.org) - не знают.

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

И большая часть этих дистрибутивов — не нужна.

Это не «типичный пример». Это, по сути, отдельная версия программы. Накладывать эти патчи перед сборкой пакета в дебиан или перед сборкой под сюзю — никакой разницы. Эти не дистроспецифично. Так что мимо.

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

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

Например, добавить конфигурационную опцию, позволяющую указать бинарник. Что сложного и зачем тупить на пустом месте?

Если your-favorite-program-name имеет зашитую в сорцы команду вызова браузера, то это действительно глупость апстрима. Пишите багрепорт.

И что, есть гарантии что апстрим (тем паче, «глупый») обязательно сочтет это багом?

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

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

Я намекаю вам на то, что проблема хуков вами «несколько» преувеличена.

Как можно «несколько преувеличить» вариант «оно поломает мне все нахрен»? Это самый элементарный пример нетривиального функционала при дистрибуции ПО. Либо вы объясняете как воспроизвести его не хуже чем сейчас и с меньшим гемороем, либо смыслу в ваших прожектах - нуль.

И большая часть этих дистрибутивов — не нужна.

Достаточно и 4-5. Если вы не найдете столько «нужных», использующих формат RPM - принесите в студию определение «нужного».

Пацаны (apache.org) - не знают.

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

Там же рядом совершенно спокойно лежат бинарные вендовые инсталляки Томкатов разных версий.

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

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

Вот и представьте на секунду, что сюзя — это «дебиан с ястом и с человеческим лицом» (ну или с каким они там лицом себя позиционируют? не особо в курсе их политики). «Портирование» и «сопровождение» свелось бы к подключению пользователем другого репозитория.

Например, добавить конфигурационную опцию, позволяющую указать бинарник. Что сложного и зачем тупить на пустом месте?

Это нужно делать в апстриме.

И что, есть гарантии что апстрим (тем паче, «глупый») обязательно сочтет это багом?

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

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

По факту, эти ваши «дистроспецифичные патчи» кочуют из дистрибутива в дистрибутив со скоростью, зависящей только от лени очередного мейнтейнера. Пока не вольются в апстрим или пока не отвалятся по естественным причинам.

Как можно «несколько преувеличить» вариант «оно поломает мне все нахрен»? Это самый элементарный пример нетривиального функционала при дистрибуции ПО. Либо вы объясняете как воспроизвести его не хуже чем сейчас и с меньшим гемороем, либо смыслу в ваших прожектах - нуль.

Можно то же самое, но по-русски? Кто поломает? Какого именно функционала? Кого воспроизвести? Кэш иконок и шрифтов обновить — это нетривиальный функционал? Или сообщение на экран и в лог вывести — нетривиальный функционал?

Что-то у нас с тобой сегодня совершенно отвратительное единодушие наблюдается.

А у меня не так:

$ ls -1 /var/lib/dpkg/info/*.list|wc -l
298
$ ls -1 /var/lib/dpkg/info/*.postinst|wc -l
204
$ ls -1 /var/lib/dpkg/info/*.postrm|wc -l
171
$ ls -1 /var/lib/dpkg/info/*.preinst|wc -l
67
$ ls -1 /var/lib/dpkg/info/*.prerm|wc -l
68

а вот с рабочей станции:

$ ls -1 /var/lib/dpkg/info/*.list|wc -l
2329
$ ls -1 /var/lib/dpkg/info/*.preinst|wc -l
274
$ ls -1 /var/lib/dpkg/info/*.postinst|wc -l
1310
$ ls -1 /var/lib/dpkg/info/*.prerm|wc -l
353
$ ls -1 /var/lib/dpkg/info/*.postrm|wc -l
1172

Что-то у нас с тобой сегодня совершенно отвратительное единодушие наблюдается.

Сам в шоке.

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

И что, я должен на нее молиться и ставить через вайн?

Полноте, молодой человек - ну кому в здравом уме нужен апач на винде :)

в зоопарке люниксов такого сделать невозможно

«Такое» - возможно. Просто нафиг никому не надо, этот msi там «чтобы было».

В том же дебиан конфигурация апача сделана удобнее и гибче. Так что идите вы в баню с подобными «best practices» от авторов. Либо последние недоумки (что маловероятно), либо вы их существенно недооцениваете и поняли неправильно.

Вот и представьте на секунду, что сюзя — это «дебиан с ястом и с человеческим лицом» (ну или с каким они там лицом себя позиционируют? не особо в курсе их политики). «Портирование» и «сопровождение» свелось бы к подключению пользователем другого репозитория.

Т.е. в вашем мегаконфиге сборки будет туча if, включающих/выключающих отдельные патчи? Для платформ, дистрибутивов, релизов...

А зачем надо-то такое? _Уже_ есть.

Это нужно делать в апстриме.

Будете всех строить. Я автор - что хочу, то и ворочу. Вам не знаком такой ответ? - значит маленький ишшо.

Как я уже сказал, патч «добавить поддержку опции конфига» не является дистроспецифичным. Ни в коем разе.

Тем не менее - где патч есть, а где-то нет и не предвидится. Специфика-с.

По факту, эти ваши «дистроспецифичные патчи» кочуют из дистрибутива в дистрибутив со скоростью, зависящей только от лени очередного мейнтейнера. Пока не вольются в апстрим или пока не отвалятся по естественным причинам.

Факты в студию, пожалуйста.

Можно то же самое, но по-русски? Кто поломает? Какого именно функционала?

Ну вот, к примеру.

У кого-то УМВР, мне же повезло меньше.

Т.е. в вашем мегаконфиге сборки будет туча if, включающих/выключающих отдельные патчи? Для платформ, дистрибутивов, релизов...

Окститесь, каких if-ов?

Будете всех строить.

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

Специфика-с.

Высосанная из пальца, ага.

Обновление Pacman в Arch Linux (комментарий)

Ваши ссылки не открываются. Вот правильная ссылка: Обновление Pacman в Arch Linux (комментарий)

И что, все 200 хуков про «изменения каталогов данных или путей к конфигурационным файлам, включают/выключают модули апача или php, обрабатывают обновление версии mysql с 5.0 до 5.1, удаляют что-то при purge и т.п.»?

На второй машине вообще жуть. ТЫЩА ТРИСТА postinst хуков. Простите, нафейхоа? Что в них? Распределенный призыв ктулху?

что характерно, в отношение debian (или centos) подобного там не замечено :)

может разруха-то не в клозетах (yandex), а в головах (дистрибутиве)? ;)

И что, я должен на нее молиться и ставить через вайн?

Ты должен отметить, что спорол херню про «пацаны из апач.орг не знают, где их собственный софт должен хранить конфиги».

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

Типичный пример идиотии апстрима, кстати, — cupsd, гадящий в /etc/ как будто это его собственный /var/lib/* . В дебиане накладывают патчи, заставляющие его гадить пореже.

Вот такие они, «дистроспецифичные» патчи.

Окститесь, каких if-ов?

Я написал каких. Условный выбор, с кучей вариантов. Или как?

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

У автора может быть свое мнение. Не обязательно его заочно обзывать идиотом.

Но если при этом этот кто-то мешает в кучу изменения функционала и дистроспецифичные вещи — он тоже идиот.
Высосанная из пальца, ага.

Если кто-то не видит, что патчи присутствуют только в конкретном дистрибутиве - он попросту слеп. Для справки:

СПЕЦИФИ́ЧЕСКИЙ, специфическая, специфическое; в качестве кратк. употр. специфичен, специфична, специфично (от лат. species - вид и facio - делаю) (книжн.). Составляющий отличительную особенность кого-чего-нибудь, свойственный исключительно кому-чему-нибудь.

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

И что, все 200 хуков про «изменения каталогов данных или путей к конфигурационным файлам...

Все двести я не смотрел (как и вы в своем примере, нет?). Случайная выборка. Так в науке поступают, знаете-ли.

На второй машине вообще жуть. ТЫЩА ТРИСТА postinst хуков. Простите, нафейхоа? Что в них?

Да примерно то же, что и на первой. Всякие update-menus и update-mime - также присутствуют, конечно.