> С разработчиком ядра логично сравнивать разработчиков ядра.

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

То есть в чём проблема: _везде_ плохо. (мальчикам-прянишничикам: у ваших ещё хуже)

>>> Не знаю что там до вас долетае...
>> Например, необходимость прописывать зависимости ручками.
> Вы имеете ввиду в Build-Depends?

В том числе.

> Но телепатии пока не изобрели

Да, но http://lists.altlinux.org/pipermail/devel/2011-December/1927...

> и разработчиков ходить строем с чем-то стандартным типа ./configure && make &&
> make install - не приучили и не предвидится.

Снабжённые головой и так уже сообразили, чем "обычные" варианты лучше "необычных".  И этих "обычных" не так уж и много.

> Увы, доклад не показывает пути решения данной проблемы.  Даже намека.

Боюсь, просто не желаете воспринимать (NIH?).  Но не настаиваю.

> Зачем автоматически класть в дистрибутив что-то "абы было"?

Не "абы было", а "с минимальными усилиями, как только понадобится".  Статистику на http://www.debian.org/devel/wnpp/ наверняка же видели -- там далеко не нули.

>>> причем подготовка пакета достаточно хорошо автоматизирована.
>> Ну с тех пор как тот кромешный ужас на старом dh в debian/rules стал необязателен
>> -- эту подготовку можно не называть пыточной камерой хотя бы ;-)
> Он не был и до.

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

Совершенно позорное для дебиана место и непонятно, как оно столько прожило.  Вот уж нашли что защищать.

PS: ещё один пруфлинк как раз в руки пришёл: http://projects.deepnet.cx/trac/debbuild

> Нелишне подчеркнуть, что "проблемы" первоначальной подготовки пакета -
> сильно преувеличены.

Можно поинтересоваться, сколько пакетов Вы первоначально подготовили?

> Основное время мейнтейнера занимает

Это всё очень сильно зависит от того, насколько сложен/устоялся упаковываемый.

>>> А вот зачем мейнтейнерам перл в Debian заморачиваться [...] ?
>> Полагаю, Вы к таковым не относитесь -- потому предложу за них и
>> не выступать.  Перловку в альте немного майнтейню, если что.
> Альт здесь нерелевантен, извините.

Видите ли, задачи по майнтенансу во многом перекликаются.  А поскольку не знаю Ваш опыт, то и спрашиваю вполне искренне, как он соотносится.  Потому что мой одиннадцатилетний опыт поддержки пакетов в альте -- с регулярными визитами в самые разные иные репозитории именно по сборочной части -- заметно более релевантен, чем опыт несобирающего _пользователя_ Debian, применительно к вопросу сборки пакетов в Debian.  Ничего личного.

> Кое-кто порядком покоцал цитату из меня любимого - и убрал знак вопроса в конце.

Простите, всего лишь постарался оставить главное; восстановил.

>>> Пока у меня складывается плохое впечатление о вашем коллеге.
>> линуксовод со стажем, сишник.
> Да будь он хоть трижды ГСС и полный кавалер ордена Славы :) [неправильно понятое skip]

Что-то я тоже всё меньше Вас понимаю и это огорчительно.

>> Внимание, вопрос: для каких задач тогда пригоден Debian stable?
> Вопрос философский.  Зачем человеку компьютер?  Даже не знаю что сказать.

Вот и я не очень понимаю, хотя теоретически несколько use cases и представляю -- например, когда разработка чего-либо хорошо синхронизируется с unstable/testing и можно позволить себе риски откладывания формального релиза stable, выпуская свой продукт.

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

> Жаль, конечно, что ожидания человека в отношении дистрибутива не оправдались.

Да ладно, это всё про выводы.  Хотя также и на заметку тем, кто на всякий чих будет советовать Debian testing и говорить, мол, сам сижу и всё хорошо.  Т.е. хоть предупреждайте, что тогда надо отслеживать...

>> Если нет автоматической сборки, нечего замахиваться на автоматическое тестирование
> Это почему так?  Ручное тестирование кучи пакетов - оно на порядок сложнее,
> собственно, подготовки самой сборки (правка метаинформации, скриптов и т.п.).

Вот ровно потому, что автоматизация тестирования ещё сложнее.

> Особенно, для "интерактивных" программ (слыхал, что в opensuse что-то ковыряли
> на эту тему, но искать лень).

В альте тоже ковыряли, что характерно.  И для инсталяторов тоже.

>>> По содержимому доклада выше - так и не понял что конкретно криво в Debian.
>> Рукопашный подход.
> Емм...  А в ALT есть аналог, к примеру, puiparts?

Проверка устанавливаемости пакетов интегрирована в сборочную систему: http://git.altlinux.org/people/ldv/packages/?p=girar-builder...

> А lintian, а debcheck?

Есть целый http://www.altlinux.org/Repocop авторства того же Игоря Власенко, а также обязательный sisyphus_check.  Некоторые пользуются и rpmlint, но его прохождение не является обязательным.

> Упрекать Debian в недостатке автоматизации - крайне несправедливо, имхо.

Обычно да, но смотря с чем сравнивать.

>>> А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров.
>> Было и сопоставимое с Debian лет десять тому, это тоже не работает.
> Но в дебиан-то, вроде, работает?

Скорее тоже нет, см. WNPP (о применимости выпусков допрошу ещё коллег-дебианщиков при случае).

>> Не уверен.  По крайней мере watch-файлики изобрели в дебиане
> Так вот это и есть реальная автоматизация.  Более того, она действительно
> *работает*.

Так честь и хвала :)

>>> Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org.
>> Можно [ссылку на] список?
> Откройте цитированный адрес - там в вики есть обзор деятельности команды.

Открыл, за разумные несколько минут не нашёл, закрыл.  Собственно, по ченжлогам она видна и это хорошо.

> Кое-какие из сервисов я упомянул выше.

Ответил.  Собственно, буду только рад, если изобретут и в дебиане.

> "Ископаемое" - это эмоционально и необъективно.

Извольте, термин debian stale не я придумал.  Можно подобное игнорировать, конечно.

> Вот не нужно, чтобы ко мне "плавно перетек" Gnome3 из апстрима.

Для этого апстрим не должен игнорировать Вас, по-хорошему...

> Что касается более специфического ПО (научное, для сервера) -
> там мастеров-ломастеров меньше и интеграция с апстрим лучше

Ой, вот давайте только без сказок про научное ПО.  Типичный случай как раз обратный, увы -- принцип "работает на моей машине" из всех щелей :(

> Вы путаете разные дистрибутивы с разными целями.

Отнюдь -- скорее задаюсь вопросом вслух.  Заметьте, меня он интересует в практическом плане; иллюзий же сам стараюсь не держать и Вам не советую.

> Принцип "when it's ready" - относится к качеству включаемого ПО.  Сдерживающим
> фактором обновления версий ПО здесь является количество RC багов, для которых
> автоматическое пакетирование новых релизов - совершенно иррелевантно.

Если такой баг -- апстримный, то может быть и релевантно.  При обеспечении возможности протестировать "сборку сбоку".

> "Быть максимально близкими к версиям upstream" - совершенно иной принцип, иная цель.

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

> Можно ли совместить их в одном дистрибутиве?  Думаю, здесь есть ресурс,
> который пока задействован в наименьшей степени - это собственно апстрим.

Отчасти да; поддержкой/образованием апстримов тоже стоит (и приходится порой) заниматься.

> Там, где он активно взаимодействует с мейнтейнерами в дистрибутиве (или сам
> играет эту роль) - с версиями проблем нет.

Да, конечно.  К слову: http://freecode.com/articles/lessons-in-packaging-linux-appl...