> С разработчиком ядра логично сравнивать разработчиков ядра.Минуточку, Инго вроде бы как не приводил дебиан в качестве исключения. Или я Вас совсем не понимаю.
То есть в чём проблема: _везде_ плохо. (мальчикам-прянишничикам: у ваших ещё хуже)
>>> Не знаю что там до вас долетае...
>> Например, необходимость прописывать зависимости ручками.
> Вы имеете ввиду в 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...
Вариант для распечатки
(ok), 17-Июн-12, 12:49 
