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

Вероятно, с точки зрения особенностей реализации RPM - это самое внятное решения (если я Вас правильно понял, это аналог упомянутых мной posttrans-скриптов, но на уровне yum'а).

Наверное, не совсем аналог, это как я понимаю предназначено для использования на месте установки пакетов, а не при их создании. Но насчет posttrans — вот похоже ровно оно, нет? http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

«%pretrans and %posttrans are available in rpm 4.4 and later»

Можно ли осуществлять автоматическую доустановку требуемых пакетов на этом этапе?

Как понимаю, можно много чего, но вряд ли мэйнтейнеру:

$ cat /usr/share/doc/yum-plugin-post-transaction-actions-1.1.23/sample.action
#action_key:transaction_state:command                                                               
# action_key can be: pkgglob, /path/to/file (wildcards allowed)                                     
# transaction_state can be: install,update,remove,any                                               
# command can be: any shell command                                                                 
#  the following variables are allowed to be passed to any command:                                 
#   $name - package name                                                                            
#   $arch - package arch                                                                            
#   $ver - package version                                                                          
#   $rel - package release                                                                          
#   $epoch - package epoch                                                                          
#   $repoid - package repository id                                                                 
#   $state - text string of state of the package in the transaction set                             
#                                                                                                   
# file matches cannot be used with removes b/c we don't have the info available                     

*:install:touch /tmp/$name-installed
zsh:remove:touch /tmp/zsh-removed   
zsh:install:touch /tmp/zsh-installed-also
/bin/z*h:install:touch /tmp/bin-zsh-installed
z*h:any:touch /tmp/bin-zsh-any

И не совсем понял, когда это может понадобиться, вместо метапакета или зависимостей.

> Доброжелательность?

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

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

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

Но если есть конкретные претензии, то почему бы не воспользоваться BTS (раздел Wishlist)?

> дебконф имеет обычные и GUI-фронтенды. всего-то делов

Заслуга дебконфа тут тогда только в меньшей костыльности их реализации. Для rpm с интерактивным %postin их же тоже можно склепать, разве что выбор из списка хз как отобразить по-человечески.

фишка в том что в .deb эта проблема давно решена уже. а в yum ее еще _можно_ решить

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

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

Ну и вдогонку. Требования все-таки должны быть более предметными, чем просто «вы уроды и инструменты у вас уродские». Самое доступное место — это wishlist в BTS, почта авторов и пр. На самом деле все кирпичики для решения задач есть уже в базовой системе. Собрались пакетики, можно их в репозиторий переносить. Есть же уже cp, mv :). Надо индексы создать? Надо и эту задачу сделать. Нужно просто наиболее гармоничным способом все эти кусочки объединить (UNIX-way же). Но самое главное — это исчерпывающая документация. Проект без документации всегда у меня вызывал чувство его заброшенности и как-то интерес еще на первых этапах знакомства пропадает. Нет документации — меньше людей будет пользоваться. Меньше людей пользуется — низкая популярность. Проект становится маргинальным.

> Не в ублюдочности дело, а в том, что как-то нет единоначалия в проектировании этих инструментов.

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

Но если есть конкретные претензии, то почему бы не воспользоваться BTS (раздел Wishlist)?

Почти все свои пожелания я находил в архивах с резолюцией «ПНХ» :) Видимо, они противоречат какой-то глубокой идеологии, которой я не понимаю. А писать патчи для apt-get - это проще сделать скрипт на коленке.

> Судя по всему, самое адекватное для пользователя упомянутой кнопки - это по окончании операции сделать некую минимальную нотификацию «Всё з..лось!» или «Ой, не шмогла!»

Я про это и говорю. Просто чел предлагал МОЛЧА ставиться в систему и если повезет юзер заметит проблему, глядя в консоль.

> Дело не в самом BSD make, а в той фигне, что понаписали на его основе, под названием 'ports'.

Как раз 'ports' со своей задачей справляется. Сливает пакетный менеджер(Внутрь лучше вообще не заглядывать). Проблема в том, что при непонимании как правильно писать на BSD make Makefile-ы превращаются в набор костылей.

> Проблема в том, что при непонимании как правильно писать на BSD make

Конкретно проблема в том, что находится внутри большинства .mk'шек. То есть, я понимаю, если туда не заглядывать с целью что-либо поменять/доработать, то, в общем, вся свалка почти и не пахнет. А если попытаться скажем, сделать систему, подобную, но не тождественную ports (ну, для некоторой специализированной области), то и выходит, что ни возможности, ни, главное, желания переиспользовать содержимое .mk'шек не возникает, увы. Для кого как, а для меня это хороший показатель качества кода и качества проектирования.

Да, диагностика нужна. И, судя по запросам пользователей, нужна кнопка — «откатить всё взад, ну её нахрен вашу новую версию!»

Ну и, если уж зашла речь про autotools с компанией, то в классических портах мешает отсутствие промежуточных артефактов, a-la ./configure, Makefile.in и т.п. Отлаживать сколько-нибудь сложный код, глядя в выхлоп make (хоть и в debug-режиме) неприятно. Хотя и возможно.

Факт работоспособности портов не оспариваю. В исходники пакетного менеджера смотрел, рыдал, смеялся, много думал, просил дать другую задачу... (: Смотрел и в содержимое ports core .mk-шек. Вот там и есть набор костылей, увы. AlexM не даст соврать (:

> Для rpm с интерактивным %postin их же тоже можно склепать

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

так что «можно склепать» = нереализованная = отсутствующая функциональность

Если проблема долго висит в статусе «можно решить», то обычно она не такая уж и проблема.

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

я очень сомневаюсь что над RPM когда-либо появится debconf

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

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

> для венды тоже можно «склепать» пакетный менеджер. однако венда как была вендой так и осталась. мало того, у чуть ли не самой богатой в мире корпорации не хватает умения «склепать».

А оно там кому-то надо? Ни разу нигде не видел жалобы виндоюзеров на отсутствие пакетного менеджера ;)

так что «можно склепать» = нереализованная = отсутствующая функциональность

нереализованная = (отсутствующая | невостребованная) функциональность. Так точнее.

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

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

я очень сомневаюсь что над RPM когда-либо появится debconf

_deb_conf точно не появится ) А так кто знает.

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

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

Q2. We do not have any type of a «click through» license for each package that is installed, and our packages aren't typically used to create a new OS image.

A2. The important point is to make sure that the end user is notified that the firmware component is governed by an Intel license and provided with a copy of the license terms prior to downloading or using the software. In the event that the package is automatically downloaded by a package update tool, and that tool provides no provision to indicate to the user that they are installing software that is covered by such a license, following A1.2 and A1.3 above is sufficient.

Особенно вторую часть ответа. Пункты 1.2 и 1.3 выше содержат только требования по части расположения текста и упоминания лицензии в системе и описании пакета. Это же оно, нет?

http://www.intel.com/support/wireless/wlan/sb/cs-016675.htm

Frequently asked questions on the firmware license for Linux

> в пятый раз приведу в пример - интеловый фирмварь для вайфаев. лицензия требует быть показанной пользователю.

Решено в Сюзе (по крайней мере, для Нвидиевых драйверов). Как - не знаю, но, судя по всему, штатно (в смысле, без особого костыля именно для этого пакета).

http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/

Для всех интересующихся. Список вкусностей внушает.

Так нвидиевские закрытые в той же федоре тоже молча ставятся.

Так нвидиевские закрытые в той же федоре тоже молча ставятся

В том-то и компот, что в Сусе (по крайней мере, в OpenSUSE 9.2 (?) и 10.x, с прочими не сталкивался) они ставятся zypper'ом (и соответствующим yast'овым GUI front-end'ом) не молча, а с демонстрацией лицензионного соглашения. С учетом того, что RPM все-таки задумывался для автоматического неинтерактивного развертывания ПО, это произвело на меня неприятное впечатление. У zypper'а, правда, есть опция для автоответа на все вопросы согласием, но осадок остался

Интересно. Посмотрим через пару лет, что будет в федоре и мандриве.