После многократного переноса тестовых версий openSUSE 12.2 стало ясно, что выпустить релиз в срок не удастся и разработчики выступили (http://news.opensuse.org/2012/06/14/where-is-my-12-2-my-king.../) с инициативой проведения реорганизации процесса разработки, что по их мнению поможет решить наблюдаемые в настоящее время проблемы с масштабированием организации разработки в условиях растущей пакетной базы.
Стефан Калаф (Stephan Kulow), релиз-менеджер openSUSE, указал (http://lists.opensuse.org/opensuse-factory/2012-06/msg00468....) на то, что текущая модель разработки неэффективна и проекту требуются новые идеи по исправлению сложившейся ситуации. В качестве одного из вариантов, предложенных Сетфаном, называется уход от плановой подготовки новых версий, которые сейчас выпускаются строго раз в 8 месяцев, к модели без жестких планов, основанной на готовности дистрибутива, или к заметному расширению сроков подготовки новых версий, например, переходу к выпуску релизов раз в год.
В качестве мотива такого предложения называется то, что несмотря на приближение даты релиза, наблюдается высокая степень нестабильности в репозитории Factory, в рамках которого ведётся стабилизация пакетов для новых версий openSUSE. Предполагается, что проблемы вызваны быстрым ростом пакетной базы и увеличением числа неподдерживаемых пакетов. В настоящее время в Factory допускается нахождение слишком большого числа пакетов, которые находятся в неработоспособном состоянии неприемлемо длительное время. Переход системы сборки на GCC 4.7 только усугубляет ситуацию.
Среди предложений, высказанных другими представителями сообщества, также можно упомянуть переход к модели непрерывного цикла обновления пакетной базы (Rolling-release), при которой обновления пакетов будут выходить постоянно и пользователь в любой момент сможет перейти на последние версии программ. Но такое предложение вызвало неоднозначную реакцию разработчиков, поэтому внедрение её маловероятно.
Что касается подготовки openSUSE 12.2, то для обеспечения полной готовности выпуска вместо планируемого 11 июля, предлагается (http://lists.opensuse.org/opensuse-project/2012-06/msg00141....) перенести релиз на середину сентября. В частности, на следующей неделе предложено выпустить вторую бета-версию, после чего отделить ветку openSUSE:12.2 из Factory для перехода на фазу заморозки, подразумевающую только исправление ошибок. В середине июля планируется подготовить первый кандидат в релизы, а в августе дополнительные тестовые выпуски. В настоящее время данное предложение ещё не утверждено разработчиками, но даже если оно будет отвергнуто, релиз openSUSE 12.2 будет отложен как минимум на две недели.URL: http://news.opensuse.org/2012/06/14/where-is-my-12-2-my-king.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=34108
а говорили, что у Дебиана не правильный подход :)
> Кто сказал, что в дебиан побегут? Самый ненужный дистрибутив.В первой пятерке ненужных дистров сама суся. Он нестабильный, обновляется редко, настраивается через какие-то костыли, которые в итоге не работают, но мешают настроить систему самому.
Я вообще удивлен, что у них народу вдруг прибавилось, а не наоборот. Там кроме хамелеона (эмблема) ничего хорошего нет.
Поддерживаю, почти всё верно сказано, только...
там ещё zypper есть - самый удобный и полнофункциональный менеджер пакетов (apt-get,pacman отдыхают)
Очень удобный, на первый взгляд, конфигуратор YaST, причём консольный и новичкам очень удобно в нём конфигурировать, но когда опыта становиться больше, далеко не у всех правда, начинаешь замечать что это убогий неудобный костыль и вручную править конфиги и удобнее и легче, а потом когда смотришь конфиги, понимаешь что он их просто изговнял.
Например при настройке виртуальных хостов в апаче, если через него их настраивать, то он чёрт знает как объеденяет отдельные файлы конфигов в единый файл и групирует по своему...
И так со всем...
Посему для неопытных новичков, каким и был я, это самое оно, но для тех кто по умнее добро пожаловат на Arch.
Я тоже был (а может и остаюсь) новичком и даже считал сусю простым удобным дистром с конфигурялками. Это ложное впечатление. Этот дистр сложный, об этом пишут в вики. Надо не только понимать как работает линукс, но еще и уметь пользоваться всеми сусевскими костылями, разбираться в их ошибках и обходить фатальные глюки. Пакеты очень сложные для собирания самому, а в репах нет многих программ. Их система сборки отнюдь процесс не упрощает. Сам дистр стоит в стороне от мейнстрима в виде редхата и ее клонов, пакеты от них подходят далеко не все. Вики недостатоно полное и переведенное.
Обновляется дистр редко. Новых версий программ с каждым месяцем хочется все больше.
Он по идее, похож на идеальный дистр для новичков и массового пользователя (убунта таковым уже не станет, это очевидно). Установка прог в 1 клик - прикольная вещь. Только до юзабильного состояния его все еще не доведут. Может и выкарабкаются.
> Сам дистр стоит в стороне от мейнстрима в
> виде редхата и ее клоновдебиана, убунты, арча и многих прочих. Не смущайтесь, так и говорите, все взяли у редхата накатили свои опознавательные знаки и мейнстрим готов.
Во, сразу видно - звездун, который Арча в глаза не видел.
Арч собран с нуля по LFS с оглядкой на Crux и FreeBSD. Так что про клона РХ - мимо лужи.
> Во, сразу видно - звездун, который Арча в глаза не видел.
> Арч собран с нуля по LFS с оглядкой на Crux и FreeBSD.
> Так что про клона РХ - мимо лужи.Да, да. Ссылку в студию. Где вклад LFS, или им все с неба сыпится. Такой себе Рог Изобилия. Взять взятое, это уже называется собственным. И кто тут звездун.
А теперь перечисли, что в Арче от FreeBSD.
А где я написал, что в Арче что-то взяли из FreeBSD? "С оглядкой" - значит "подсмотрели и сделали похоже", только лучше, конечно.
А глядели на систему инициализации. Сейчас потихоньку systemd проникает.Джадд собрал Арч с нуля: "Arch is independently developed, was built from scratch and is not based on any other GNU/Linux distribution." Это из FAQа.
А ссылка: https://wiki.archlinux.org/index.php/FAQ
> Джадд собрал Арч с нуля: "Arch is independently developed, was built from
> scratch and is not based on any other GNU/Linux distribution." Это
> из FAQа.С нуля взяв вклад редхата в ядро, gnome и прочую ерунду.
Оттого, что РХ делает вклад в ядро, гном и т.д. не вытекает, что все дистры - клоны РедХата. Космонавт - один из крупных вкладчиков в KDE, но ты же не станешь утверждать, что Мандрива - клон Убунты.Вопрос на засыпку, чей вклад взял РедХат и чьим клоном он должен быть, если на тот момент момент уже были Slackware и Debian?
Хоть одну статью написал/перевел?
> вручную править конфиги и удобнее и легче, а потом когда смотришь
> конфиги, понимаешь что он их просто изговнял.А нефиг руками туда лазит, либо Yast либо руками.
Я знаю, надо вам бинарный формат сделать, чтоб свои кривые руки не сували
> Например при настройке виртуальных хостов в апаче, если через него их настраивать,Только мужикам не говори, что Апачь настрагиваешь через гуй, зачмырят как говно последнее.
---
В прочем я рад, что моем любимом дистре не прибавится дебилов.
И это пишет тот, кто жаловался, что мол анонимы говном поливают без повода, а сам говно расплёскивает ещё гуше...И это пишет тот, у кого на сервере иксы и без гуйного яста вообще конигурировать не умеет...
Апач я года 3 назад когда сузю поставил первый паз конфигурировал через яст, сейчас я даже сеть настраиваю не через него, кроме управления пакетами я его вообще не для чего не использую...
Конфигураторы НЕ должны говнять конфиги, или нах такие конфигураторы вообще сносить! ИМХО
> И это пишет тот, у кого на сервере иксы и без гуйного
> яста вообще конигурировать не умеет...Дятел чтоль? Какой нахёр сервер? У меня на всех серверах Debian.
> Конфигураторы НЕ должны говнять конфиги, или нах такие конфигураторы вообще сносить!YaST не говнит конфиги! Это ты их изговнил когда руками полез.
> а говорили, что у Дебиана не правильный подход :)Самый правильный подход - у убунты: забить болт на баги, выпустить точно в срок. Его эффективность наглядно подтверждается рейтингом популярности дистров.
> Самый правильный подход - у убунты: забить болт на баги, выпустить точно
> в срок. Его эффективность наглядно подтверждается рейтингом популярности дистров.А не факт что лучше: софт с багами или доисторический софт из эпохи мезозоя. Который тоже с багами, баги починеные апстримом там в общем случае не фиксят и только бэкпортят секурити фиксы, а еще как бонус - нужной фичи может не оказаться.
Впрочем, у любого дистра и ОС - своих проблем навалом. Можно подумать что это самые хучшие.
Есть дистры лишенные обоих этих проблемм. Роллинг чего-то там
openSUSE Tumbleweed, оно?
> openSUSE Tumbleweed, оно?Подобные не для всех в плане время- и трудозатрат за среднепотолочный год пользования. Т.е. на локалхосте (как вот пишу с сизифа) -- ещё может быть, а на поддерживаемых ради других людей хостах в плывущие ABI лучше не играться.
Самый правильный у Arch linux. Вот только неофитам он не по зубам, работая в нём надо головой думать, прежде чем изменять настройки и т.п. Всё ручками делается, и головой... Это не мартышкин труд(кнопконажимательство в Arch не в почёте).
и gentoo. я бы вообще рекомендовал неофитам начинать с минимала. те, кто останутся - будут толковыми.
А вам не кажется, что слишком много чести операционке - постоянно разруливать особенности обновления, подправлять конфиги и т.п.? Лично я предпочитаю тратить свое время на работу более творческую
>> а говорили, что у Дебиана не правильный подход :)
> Самый правильный подход - у убунты: забить болт на баги, выпустить точно
> в срок. Его эффективность наглядно подтверждается рейтингом популярности дистров.Батенька, а не задумывались ли Вы на счет того, почему у сис.админов на работе RH, Centos или Debian, а дома Ubuntu? Ответ прост - через 3 года "это" будет стоять у них на серверах! Будете спорить?
> Батенька, а не задумывались ли Вы на счет того, почему у сис.админов на работе RH, Centos или Debian, а дома Ubuntu?Потому что таких "сисадминов" надо с работы гнать? :) Угадал? На работе они, понимаешь, Debian настроили - а дома десктоп из него сделать ниасилили.
А лучше - отучаемся говорить за "всех".
> Батенька, а не задумывались ли Вы на счет того, почему у сис.админов
> на работе RH, Centos или Debian, а дома Ubuntu? Ответ прост
> - через 3 года "это" будет стоять у них на серверах!
> Будете спорить?Нет. В массовые решения всегда вылезают кхм... самая лёгкие фракции. Из всех ОС - Windows. Из всех линуксов - убунта. Ну и далее.
> Его эффективность наглядно подтверждается рейтингом популярности дистров.Если Вы про distrowatch, то спорить сложно -- пользователи массово перебираются на Mint...
>> Его эффективность наглядно подтверждается рейтингом популярности дистров.
> Если Вы про distrowatch, то спорить сложно -- пользователи массово перебираются на
> Mint...+10 к троллингу
> +10 к троллингуДа какой троллинг, я когда-то украинское зеркало дистровотча поддерживал. До сих пор иногда и поглядываю.
Другое дело, что метрика эта сама по себе тоже условная, хотя и не самая плохая -- за последние лет десять в первом приближении скорее коррелировала.
Молодцы, наконец-то будут делать не велосипед, а дистрибутив. OpenSUSE очень хорош для сервака, помнится один из моих серваков стоит на OpenSUSE 10.3 и причем с 2008г, работает отлично. Хороший дистриб, но хотелось бы чтобы mono они из него выпилили.
> Молодцы, наконец-то будут делать не велосипед, а дистрибутив. OpenSUSE очень хорош для
> сервака, помнится один из моих серваков стоит на OpenSUSE 10.3 и
> причем с 2008г, работает отлично. Хороший дистриб, но хотелось бы чтобы
> mono они из него выпилили.Кто тебя заставляет mono ставить или зузю? Нет выбора?
во-первых, правильно пишется openSUSE.
во-вторых, назови хоть один SUSE-специфичный пакет зависимый от mono?
6 месяцев, 8, 12...
Вместо того, чтобы за цифирками гнаться, может уже пора задуматься об LTS?
Да разрабам opensuse это скучно.
не все так просто. для этого есть SLE. если сделать LTS, то это ударит по SLE, и в свою очередь ударит по самим разрабам, так как они в своем большинстве и есть разрабы как openSUSE, так и SLE
> не все так просто. для этого есть SLE. если сделать LTS, то
> это ударит по SLE, и в свою очередь ударит по самим
> разрабам, так как они в своем большинстве и есть разрабы как
> openSUSE, так и SLEДля хеппи энда не хватает только того, что бы обновления для SLE были доступны. Хотя в целом цена на подписку там в разы меньше чем у шапки, но тем не менее.
см. SUSE Linux Enterprise
У них есть LTS версия. Вроде бы Evergreen называется.
эвергрин не лтс, эвергрин - костыль для подпирания систем, которые хозяева боятся обновлять на новые версии этого цир^W^W OpenSUsE.
Вместо того как за циферками гнаться, они думают как бы сделать дистрибутив лучше, ищут решения проблем.
какая тонкая ирония
для тех кто в танке - есть Evergreen.
Согласен с предыдущим постером!
И ещё... Давно пора перейти на как минимум две ветки одна пусть постоянно обновляется(жаль что они от этого метода отказались), а другая пусть будет LTS лет на 5 как минимум(а в мечтах лет на 10), с возможностью безболезненной миграции на следующий стабильный релиз!
Tumbleweed
нет нужных пакетов? а ты их туда засабмитил?
Молодцы! Если сыро ну и правильно что не хотят выпускать релиз.
> Если сыро ну и правильно что не хотят выпускать релиз.Ну и будет еще одна слака, потом серваки будут отключать - один фик нечего обновлять а потом обнаружат что это даже не волнует никого - потому что и обновления никому не нужны - все нормальные люди давно на Ubuntu перешли.
> все нормальные люди давно на Ubuntu перешли.Ну привет вам, "нормальные".
Интересно, через сколько лет Шатлворт наберётся смелости сказать, что полугодовой цикл был чисто маркетинговым кидаловом...
А можно просто пойти по пути Ubuntu - игнорировать баги и выпускать релиз as is точно в срок.
В могилу оно катится. В стабильной версии обновлений не дождешься, даже если в багзиле баг чинят за пару дней. Даже исправления безопасности выходят с задержкой в недели.
А в официально не поддерживаемых репах из obs половина пакетов либо не собираются, либо не работают.
В убунте та же фигня, и ничего, живее всех живых.
> В убунте та же фигня, и ничего, живее всех живых.Да ладно вам, в убунте свои баги они чинят а апстримные чинят апстримы :)
Грустно соглашаюсь.
> В стабильной версии обновлений не дождешься, даже если в багзиле баг чинят
> за пару дней. Даже исправления безопасности выходят с задержкой в недели.Оплачивал саппорт? Разрабы обязаны жрать ночами доширак, но выпустить патч через час анонса?
Оплачивал саппорт?Про OpenSuSe разговор, а не про SLES.
> Оплачивал саппорт?
> Про OpenSuSe разговор, а не про SLES.поэтому, отправь патч сам!
> Оплачивал саппорт?
> Про OpenSuSe разговор, а не про SLES.Так тем более, был бы SLES можно было ещё предъявлять.
А так, извините, скажите спасибо, что вообще... :)
> Про OpenSuSe разговорА кто это.
S.u.S.E Linux
SuSE Linux
SUSE Linux
openSUSEКак то так.
На Сентябрь это хорошая мысль, но лучше на вторую неделю октября!
Макс, делай коменты только авторизированных, хоть через вконтакт, твытыр, фейсб...Заипли уже анонимы, сайт в какашку превратился. Каждая тема превращается в срач.
Обвинения и недовольства вообще никак не аргументируются - вот говно и всё.
> хоть через вконтакт, твытыр, фейсб...Ты действительно этого хочешь? Натурально из вконтакта? :)
Конечно, во всем анонимы виноваты. А главное, никто не сомневается, что как только этот ник исчезнет, все сразу станет как надо.
> Обвинения и недовольства вообще никак не аргументируются - вот гoвно и всё.Это между прочим и твоих коментов касается: в 50% случаев столь же неаргументированные набросы и высeры.
Внимание, вопрос: чем твои неаргументированные высeры принципиально отличаются от всех остальных?
> Внимание, вопрос: чем твои неаргументированные высeры принципиально отличаются от всех остальных?Он же зарегистрированный! Если анонимов не, то он потребует вернуть деньги.
Друзья, выездная сессия ЛОРа? :)
Ну комменты от социалок это вопрос спорный, но вот только от зарегенных это нужно!
> но вот только от зарегенных это нужно!Милости просим на linux.kiev.ua, там ровно так и есть.
Через какое-то время согласился, что Максим был прав.
Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается. Тамблевид - слишком нестабилен, с моей точки зрения, фактори - вообще транк какой-то. Даже пакман выглядит серьёзнее. Ведро тамблевида 2 из 3 раз имеет проблемные драйвера для моего оборудования.
Поддерживаю Стефана - так жить нельзя.
> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается.Хотите стабильности - пользуйте SLES.
В моём случае это SLED. Вы его когда нибудь видели? И цены на него (патчи - 50 баков в год). Но и это не всё. Как я понял ветки - SLES & SLED - это для корпорасов. Для дома - опенсуся. Так что замечание не в кассу.
Преимущество линукса над виндовсом для десктопа в его стабильности и постоянном развитии. ПО стало больше и нужны новые механизмы для формирования стабильного дистрибутива.
> ПО стало больше и нужны новые механизмы для формирования стабильного дистрибутива.Откуда. Просто одной задницей на десяти стульях не сесть. Хотят быть хорошими для всех, а оно не получилось. kde3, kde4, gnome2, gnome3, lxde, xfce, enlightenment. freetype1 - сколько лет уже его не существует, а его все тянут. Для совместимости со сферическим астралом, не иначе. Отсюда и качество стремящееся к нулю.
> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается.Пользуюсь сизифом более 10 лет. Некоторые поднятые вопросы живо напомнили и то, что в devel@altlinux обсуждалось -- но в общем и в целом сейчас со стабильностью скорее хорошо, кроме времён подвижек тектонических плит вроде xorg.
Стопка пруфов доступна на http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkima.../ :)
Миша, я совето-русо-путо-фоб не могу перейти на альт :) Но наверное в виртуалке поставлю...
> Но наверное в виртуалке поставлю...Да не, не стоит, если имеющееся устраивает. Ссылка была упреждающей для иных любителей подоказывать ;-)
Кстати, первый экспериментальный образ для виртуалки сегодня тоже выпек. Осталось купить турбореактивные двигатели у англичан -- ой, потырить конверсию из kiwi -- и можно взлетать!
Мой вопрос немного не в тему, но все же. Скажите можно ли переносить патчи между дистрибутивами? Например, есть некоторая функция в виде патча, но в другом дистрибутиве, могу ли я сделать пакет, для другого дистрибутива используя там этот патч? Я так же хочу после выложить этот пакет для общего доступа в виде исходного кода и бинарного пакета. Буду благодарен за компетентный ответ
Этот же вопрос интересует и к патчам исправляющим те или иные ошибки
Можно. Дебианщики так делают (по части секьюрити фиксов). Но если бы вы могли и умели правильно руками и напильником бэкпортить секьюрити фиксы вы бы таких вопросов не задавали. Поэтому вам - нельзя.
> Можно. Дебианщики так делают (по части секьюрити фиксов). Но если бы вы
> могли и умели правильно руками и напильником бэкпортить секьюрити фиксы вы
> бы таких вопросов не задавали. Поэтому вам - нельзя.За то, что ответили на мой вопрос, спасибо. А на счет всего остального: поменьше желчи
>> Можно. Дебианщики так делают (по части секьюрити фиксов). Но если бы вы
>> могли и умели правильно руками и напильником бэкпортить секьюрити фиксы вы
>> бы таких вопросов не задавали. Поэтому вам - нельзя.
> За то, что ответили на мой вопрос, спасибо. А на счет всего
> остального: поменьше желчитеперь совсем нельзя
P.S. 100% не желчь
используйте obs. автоматического создания патчей нет, конечно, но возможность централизованно иметь пачку патчей для всех популярных дистрибутивов в одном месте, собирать, тестировать и раздавать в виде репозиториев
Спасибо вам за ответ. Собственно я и хочу бэкпортировать некоторые функции с одного дистрибутива в другой. Как это сделать у меня трудностей не возникает, интересовал лишь вопрос законности применения патчей разработчиков одного дистрибутива в другом дистрибутиве.Если я, верно вас пониманию, то получается если я переношу результат работы одного сообщества в другое сообщество то в данном случае никаких препятствий и ограничений нет?
Лицензию смотри к патчам.
Если не сложно, покажите для примера где такая используется. Конечно в OpenSUSE по моему видел, но это скорее относится к spec содержимому.
> Скажите можно ли переносить патчи между дистрибутивами?Как правило, да -- но в каждом конкретном случае могут возникнуть свои нюансы (от разных веток софта, который упаковывается, до разного взаимодействия с окружением).
Например, сегодня стырил три гентушных патча и один дебиановский, поправляя сборку photoprint, и заодно в апстрим закинул. Всё просто легло, хоть и чуть разные версии.
Так что лучше конкретизировать.
PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи. Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к легитимному применению.
> PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи."Вы мне запрещаете?" (c)
> Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к
> легитимному применению.Что не обязывает патчи лицензий не иметь вовсе. Или иметь совпадающую с исходниками.
В Debian большая часть пакетов (я не знаю контрпримеров) имеет на debian/* (в т.ч. и патчи) - в качестве лицензии варианты GPL. А в архиве есть исходники с самыми разнообразными лицензиями.
Use common sense, Luke!
> Use common sense, Luke!common sense как раз и подсказывает, что лицензия на патч (особенно тривиальный) -- такая же, как и на тот исходник, разницу с созданной на основе которого производной работой он и описывает.
Если Вы не ошиблись, то занудство дебианщиков могло обернуться против них на первой же софтине с GPL incompatible license -- но такое бы явно уже вскрылось.
> common sense как раз и подсказывает, что лицензия на патч (особенно тривиальный)
> -- такая же, как и на тот исходник, разницу с созданной
> на основе которого производной работой он и описывает.Не логично. Как на остальной кусок работы по пакетированию (сдержимое debian/, к примеру). Это - логично.
> Если Вы не ошиблись, то занудство дебианщиков могло обернуться против них на
> первой же софтине с GPL incompatible license -- но такое бы
> явно уже вскрылось.Да чего уж тут "занудство". Также, вполне логично - людям лень выписывать на каждый debian/patches/01_bla-bla.patch - отдельный крендель в copyright (а сабмиттеры патчей не настаивают на откровенном legal-маразме). Вот и лепят на весь debian-stuff - одну лицензию. Естественно, она обязана быть совместимой с исходниками, дабы весь пакет целиком отвечал DFSG.
>> лицензия на патч (особенно тривиальный) -- такая же, как и на тот исходник,
>> разницу с созданной на основе которого производной работой он и описывает.
> Не логично.Исходники и патчи -- данные, debian/{copyright,rules} -- метаданные. Почему нелогично?
Я могу и более строго пояснить, но это будет очередной офтопик.
> Вот и лепят на весь debian-stuff - одну лицензию. Естественно, она обязана
> быть совместимой с исходниками, дабы весь пакет целиком отвечал DFSG.Так это ж совсем другое дело. :)
// кажется, опять перезанудствовал дебианщиков -- брр, срочно на озеро
Уже, млин :(. Выпилили libreadline >> несъедобный интерфейс пострги, выпилили openssl >> гнутая версия глючит при постановке сессии с рядом клиентов (TheBat! smtp over tls, например). А что ядро у них не суспендится под xen'ом, это вообще выше моего понимания - такой херни даже в убунте нет.
Итог = Debian потерял для меня смысл как серверный дистрибутив, а жалко - на ряде задач с RHEL-клонами возиться существенно дольше.
> Итог =Грустно слышать :( Может, хоть багу на тот же Pg им повесите, вдруг переобсудят?
>> Итог =
> Грустно слышать :( Может, хоть багу на тот же Pg им
> повесите, вдруг переобсудят?Да, всё уже переобсужено и починено. http://bugs.debian.org/607907
Чтоб GNU readline _фактически использовался в pgsql, его нужно доставить в систему, т.к. его нет в зависимостях пакета, а бинарник собирается с _бинарно-_совместимым editline^Wlibedit из-за лицензионных ограничений, насколько я помню, таки _openssl.
Это (установка целого одного пакета руками), конечно, славная причина "свалить с" и "трахаться с". ///Да, конечно, я опять ничего не понял.
Причина для меня = ядро не суспендится под xen'ом, остальное - да, решается костылями.
Вон, в убунте 12.04 расфаршмачили /etc/network/interfaces (перепутан порядок запуска интерфейсов в апстарте), но это не блокирующий баг (хотя ограничивает область испоьзования) и на него в рабочем порядке запилили костыль. А вот криво собранное ядро - это уже в морг, у нас нет штата заниматься сборкой/отладкой для боевых систем.
>[оверквотинг удален]
> Как правило, да -- но в каждом конкретном случае могут возникнуть свои
> нюансы (от разных веток софта, который упаковывается, до разного взаимодействия с
> окружением).
> Например, сегодня стырил три гентушных патча и один дебиановский, поправляя сборку photoprint,
> и заодно в апстрим закинул. Всё просто легло, хоть и
> чуть разные версии.
> Так что лучше конкретизировать.
> PS: "лицензии к патчам" не бывает, бывает к исходникам, на которые патчи.
> Т.к. патчи с несовместимой лицензией были бы автоматически непригодны к
> легитимному применению.Спасибо вам за ответ, вы реально мне помогли. На самом деле, некоторое время назад, я видел в Gentoo патчи от Fedora. И единственное что было приложено к патчу, это текст, мол взято из федоры. Я пошел таким же путем, пишу источник патча точнее имя пакета с которого я его взял. Свои патчи оставляю без комментариев, думаю, что оно и так ясно кто их сделал.
Еще раз спасибо за помощь
> Свои патчи оставляю без комментариев, думаю,
> что оно и так ясно кто их сделал.И напрасно.
Вспомните трамвай Аннушки! И будет следующий мейнтейнер гадать откуда взялся патч и нафига он вообще нужен.
В дебиане для подобного есть (опциональный) стандарт (http://dep.debian.net/deps/dep3/) метаинформации к патчам.
> На самом деле, некоторое время назад, я видел в Gentoo патчи от Fedora.
> И единственное что было приложено к патчу, это текст, мол взято из федоры.
> Я пошел таким же путем, пишу источник патча точнее имя пакета
> с которого я его взял.Тут есть два момента:
- credit where credit is due (в смысле отдать должное, а не "в кредит");
- практическая сторона вопроса, т.е. сверяемость/воспроизводимость.Сам стараюсь (но по лени не всегда так делаю) отмечать, из какой в точности версии-сборки пакета утащен патч; и опять же по лени в следующий раз проделывать то же самое стараюсь и чужие патчи более-менее очевидного толка (например, фиксы сборки с новыми gcc/autotools/...) отправлять авторам софтинки.
Обычно полезно включить название источника в имя файла с патчем -- см., например, http://www.altlinux.org/ALT_Packaging_HOWTO#.D0.9D.D0.B0.D0....
> Свои патчи оставляю без комментариев, думаю, что оно и так ясно кто их сделал.
Комментарии можно писать в том же RPM spec около Patch: -- либо в письме разработчикам или заявке на включение патча. В простом случае и полстроки достаточно.
Почему патчи лучше мержить -- см., например, http://vimeo.com/23522095
Правильно делают, версия 12,1 глюкавая получилась.
> Пользуюсь ОпенСусей более 5 лет. Стабильность постоянно снижается
> Правильно делают, версия 12,1 глюкавая получилась.Хоть тут и критикуют подход Каноникла к выпуску релизов, но нельзя не согласится со сказанным выше - качество релизов суси неуклонно снижается. 12.1 ужасен. Не припомню ни одного случая, чтобы после успешной установки с Livecd система после grub вылетала в kernel panic, на другом компе все работает, но печалит многочисленными багами и тормознутостью.
В убунту с такими эпичными багами не сталкивался.
Передайте им, что при наличии OBS репозитарий им просто не нужен. Соответственно, никаких проблем со сроками — главное стабилизировать основное окружение, остальное собирать отдельно. Релиз делать через месяц после стабилизации, чтобы не оказаться с пустым набором софта.Правда, роллинг в этом случае совсем не гарантирован.
Одному мне показалось что Вы показали Windows-way?
> Одному мне показалось что Вы показали Windows-way?Увы, нет, очень многие путают микрорепозитарии а-ля PPA или OBS (а теперь ещё и ABF) с нестандартными инсталляционными пакетами, как это принято в Windows, или в лучшем случае с MSI/DMG. Однако это не так, репозитарии остаются репозитариями, вне зависимости от того, на сколько они большие.
Вы пока разницы не показали. Если программа не пользуется тем, что в системе, а тащит с собой - это либо тестовая программа, либо виндовс.
Вот в этом их и проблема, они не могут определится с основным окружением. Набрали горы барахла и стыкуют его с новым gcc-4.7.
> Например, после обновления версии сам пакет можетработать без проблем, но работоспособность связанных с ним пакетов часто нарушается.
Поэтому gentoo forever!
> В качестве одного из вариантов, предложенных
> Сетфаном, называется уход от плановой подготовки
> новых версий, которые сейчас выпускаются строго
> раз в 8 месяцев, к модели без жестких планов, основанной
> на готовности дистрибутива, или к заметному расширению сроков подготовки новых версий,
> например, переходу к выпуску релизов раз в год.Я не понял, а где Шигорин со своим
"Да! А я им это еще n лет назад говорил!"? :-)
>> например, переходу к выпуску релизов раз в год.
> Я не понял, а где Шигорин со своим
> "Да! А я им это еще n лет назад говорил!"? :-)Как где, в архиве: https://www.opennet.ru/openforum/vsluhforumID3/50315.html#19 (n > 3)
>переход к модели непрерывного цикла обновления пакетной базы (Rolling-release)Вот это реально нам и надо, как в Arch и никаких проблем.
>...перенести релиз на середину сентября...на следующей неделе...перехода на фазу заморозки...Это и так устарелый пакеты (libreofice php postqresql mariadb mysqlworkbench geany memcashed) ещё и замарозят на 3 месяца...
Не я точно валю на Arch!
Я тоже пользуюсь openSUSE более 5 лет. Часто ради собственного интереса ставлю на попробовать Бета-версии. Проблема снижения качества отладки дистрибутива перед релизом мне понятна. Я согласен с тем, чтобы релизы выходили реже, например раз в 10 месяцев, но более качественные. Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...
> Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...См. тж. анализ Игоря Власенко: http://ftp.linux.kiev.ua/pub/conference/peers/lviv/2012/Vlas...
>> Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...
> См. тж. анализ Игоря Власенко: http://ftp.linux.kiev.ua/pub/conference/peers/lviv/2012/Vlas...Плач Яросл^Wальтовцев это, а не анализ. И все сказошные аналогии с феодализмом - увы, основаны только на проблемах конкретного комьюнити. Debian имеет раза в два большую пакетную базу, но никто не жалуется.
Финал:
> Widespreading the technology will definitly change ALT Linux into a prominent distribution and make it an innovation leader.No chance. Не, ну вам, ребят - удачи, конечно...
Утилит для этого самого "automation of maintainer's work" - в том же Debian'е вагон, причем давно (куда больше интересны утилиты для автоматизации QA, а не подобные велосипеды; тем более, что буквально воровать пакеты - там неоткуда). Autoports - имеет смысл не для всякого дистрибутива (пересобрать пакет из sid в backports - еще полбеды, а сопровождать его там потом ваш autoports будет?). И т.д.
>>> Видимо, это объективная реальность - разработка дистрибутива становится все сложнее...
>> См. тж. анализ Игоря Власенко:
> Плач Яросл^Wальтовцев это, а не анализ.А, ну подождите ещё пару годиков.
> И все сказошные аналогии с феодализмом - увы, основаны только на проблемах конкретного
> комьюнити. Debian имеет раза в два большую пакетную базу, но никто не жалуется.(заглядывая в инбокс) Прямо-таки никто? Даже до меня долетает вообще-то.
> Финал:
>> Widespreading the technology will definitly change ALT Linux into a prominent
>> distribution and make it an innovation leader.
> No chance. Не, ну вам, ребят - удачи, конечно...Это был докторский вброс, да :)
> Утилит для этого самого "automation of maintainer's work" - в том же
> Debian'е вагон, причем давно (куда больше интересны утилиты для автоматизации QA,
> а не подобные велосипеды; тем более, что буквально воровать пакеты -
> там неоткуда).Если Вы полагаете, что в дебиане есть всё, то заблуждаетесь. Окиньте взглядом CPAN.
> Autoports - имеет смысл не для всякого дистрибутива (пересобрать пакет из sid
> в backports - еще полбеды, а сопровождать его там потом ваш autoports будет?). И т.д.Буквально на неделе коллега разве что не матерился на Debian testing и дрова nvidia 295-й серии, которые ему приехали вследствие желания поставить "всего лишь" одну софтинку, потянувшую новую glibc.
Вы поймите правильно: на дебиан году в 2001 я и сам собирался переходить, так что присматривался ещё с тех пор довольно внимательно. Но что криво у нас в альте или у вас в дебиане или над чем не думают (либо думают, но не делают) -- то надо уметь признать.
PS: усё, сбёг на озеро, чего и Вам желаю ;-)
PSP: пришёл. Коллеги, лето на дворе, хватит втыкать в монитор!
> (заглядывая в инбокс) Прямо-таки никто? Даже до меня долетает вообще-то.Ну, "караул" на уровне Инго - не кричат. Не знаю что там до вас долетае...
> Если Вы полагаете, что в дебиане есть всё, то заблуждаетесь. Окиньте
> взглядом CPAN.Все что попросили включить (см. BTS wnpp) - стараются включать, причем подготовка пакета достаточно хорошо автоматизирована.
А вот зачем мейнтейнерам перл в Debian заморачиваться еще какой-то специальной инфраструктурой для автоматического запихивания в архив ненужного никому хлама? Непонятно.
>> Autoports - имеет смысл не для всякого дистрибутива (пересобрать пакет из sid
>> в backports - еще полбеды, а сопровождать его там потом ваш autoports будет?). И т.д.
>
> Буквально на неделе коллега разве что не матерился на Debian testing и
> дрова nvidia 295-й серии, которые ему приехали вследствие желания поставить "всего
> лишь" одну софтинку, потянувшую новую glibc.Тут нужны подробности. Пока у меня складывается плохое впечатление о вашем коллеге. Как ни крути полученную от вас информацию:
a) коллега использует тестинг и обновлялся
b) коллега использует squeeze и подключил тестинг ради плюшки
c) иной вариант, фантазия отказывает
- он таки выглядит ССЗБ. Тестинг - это тестинг, там много чего периодически ломают. Использование микса stable+testing - официально не поддерживается. Наконец, nvidia-драйвер не часть Дебиан, вы уж извините.В варианте b) - действительно, помог бы бэкпорт.
Увы, автоматизировать полностью его принципиально невозможно. Причем даже "тривиальный" случаи уровня "добавили запись в debian/changelog и пересобрали". Если, конечно, у вас нет развернутой автоматической системы тестирования пакетов. Работы оных, а не сборки.
А вручную - бэкпорты для указанного пакета периодически делаются. Ничто не мешает помочь интересующимся людЯм ускорить процесс.
> Вы поймите правильно: на дебиан году в 2001 я и сам собирался
> переходить, так что присматривался ещё с тех пор довольно внимательно.Ну, с 2001 года Дебиан малость изменился в (ИМХО) лучшую сторону... Как, наверно, и ALT. Может пора присмотреться по-новой?
> Но что криво у нас в альте или у вас в
> дебиане или над чем не думают (либо думают, но не делают)
> -- то надо уметь признать.По содержимому доклада выше - так и не понял что конкретно криво в Debian. А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров. Боюсь, с подходом к выпуску, тестированию и дальнейшему сопровождению релизов в Debian - такое стало бы для него фатальным и никакая автоматизированная система сборки хлама с CPAN - его бы не спасла :)
Думаю, это применимо и к ALTLinux. Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org. Соответственно, сабж без хорошей системы автоматического тестирования - приведет элементарно к дальнейшему падению качества дистрибутива.
PS:
> Коллеги, лето на двореНа чужом дворе мож-т и лето.
>> (заглядывая в инбокс) Прямо-таки никто? Даже до меня долетает вообще-то.
> Ну, "караул" на уровне Инго - не кричат.Что-то не припомню сходу на том уровне майнтейнеров Debian (кроме разве kernel team).
> Не знаю что там до вас долетае...
Например, необходимость прописывать зависимости ручками.
>> Окиньте взглядом CPAN.
> Все что попросили включить (см. BTS wnpp) - стараются включатьЯ к тому, что есть огромное поле того, что люди собирают сами предоставляемыми сторонними инструментами. И CPAN тут -- это только верхушка айсберга проблемы модулей для скриптовых языков, увы. Там хоть базовая версия относительно одна.
> причем подготовка пакета достаточно хорошо автоматизирована.
Ну с тех пор как тот кромешный ужас на старом dh в debian/rules стал необязателен -- эту подготовку можно не называть пыточной камерой хотя бы ;-)
> А вот зачем мейнтейнерам перл в Debian заморачиваться
Полагаю, Вы к таковым не относитесь -- потому предложу за них и не выступать. Перловку в альте немного майнтейню, если что.
> Тут нужны подробности. Пока у меня складывается плохое впечатление о вашем коллеге.
Обычный дядька, линуксовод со стажем, сишник. Притащил его к нам netch@, кстати.
> a) коллега использует тестинг и обновлялся
И не обновлялся без веского к тому поводу, почему и получил внушение на предмет де-факто необходимости отслеживать подобные текущие репозитории хотя бы еженедельно (и разгребать/репортить проблемы по мере возникновения, а не сразу пачкой)...
> Тестинг - это тестинг, там много чего периодически ломают.
> Использование микса stable+testing - официально не поддерживается.
> Наконец, nvidia-драйвер не часть Дебиан, вы уж извините.Внимание, вопрос: для каких задачи тогда пригоден Debian stable?
> В варианте b) - действительно, помог бы бэкпорт.
О чём было второе внушение (с упоминанием альтовских autoports).
> Увы, автоматизировать полностью его принципиально невозможно.
> Причем даже "тривиальный" случаи уровня "добавили запись в debian/changelog
> и пересобрали". Если, конечно, у вас нет развернутой автоматической системы
> тестирования пакетов. Работы оных, а не сборки.Если нет автоматической сборки, нечего замахиваться на автоматическое тестирование (или автоматизацию сбора статуса -- "работает/сломано").
> А вручную - бэкпорты для указанного пакета периодически делаются.
> Ничто не мешает помочь интересующимся людЯм ускорить процесс.И вот так у них всё... если что, я майнтейнил коллекцию альтовских бэкпортов в целом несколько лет и немножко знаю, чего такое стоит интересующимся.
>> Вы поймите правильно: на дебиан году в 2001 я и сам собирался
>> переходить, так что присматривался ещё с тех пор довольно внимательно.
> Ну, с 2001 года Дебиан малость изменился в (ИМХО) лучшую сторону...Конечно.
> Как, наверно, и ALT. Может пора присмотреться по-новой?
Альт местами точно в худшую, в 2001 не было глупых однобайтовых ляпов в релизах.
С дебиана я бы не стал перебираться на альт (как и с альта на дебиан), а вот чего почерпнуть у соседей -- может и найтись.
> По содержимому доклада выше - так и не понял что конкретно криво в Debian.
Рукопашный подход.
> А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров.
Было и сопоставимое с Debian лет десять тому, это тоже не работает. Собсно, перечитайте новость.
> Боюсь, с подходом к выпуску, тестированию и дальнейшему
> сопровождению релизов в Debian - такое стало бы для него фатальнымНе уверен. По крайней мере watch-файлики изобрели в дебиане -- стало быть, и те люди скорее всего предполагали, что увеличить циферку и попытаться собрать может и робот, а вот человеку лучше побольше времени оставить читать NEWS или коммиты и проверять работоспособность, освободив при возможности от лишней рутины.
> Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org.
Можно [ссылку на] список? Смутно припоминается, что чего-то действительно не хватало -- но в дебиане не припоминаю, например, реализованной в масштабах всего main проверки на разрешимость ELF-символов.
> Соответственно, сабж без хорошей системы автоматического тестирования -
> приведет элементарно к дальнейшему падению качества дистрибутива.Проблема вкратце такова: либо релизить "when it's совсем ready" и пользоваться заслуженной репутацией ископаемого, либо перераспределять и подпирать _ограниченный_ ресурс человеческого внимания так, чтобы протекание кода из апстримов к пользователям происходило с минимальными накладными расходами и максимальным отловом проблем по дороге.
Кстати, будет интересно посмотреть, как эта самая проблема повлияет на взаимодействие Debian и Ubuntu. Особенно если у них не найдётся толкового д.м.н. подумать заранее.
>> PS: Коллеги, лето на дворе
> На чужом дворе мож-т и лето.Дык приезжайте ;-) Аж подгорел малость за час-полтора...
> По крайней мере watch-файлики изобрели в дебиане -- стало
> быть, и те люди скорее всего предполагали, что увеличить циферку и
> попытаться собрать может и роботАналог "watch-файликов" был ВСЕГДА в source-based системах, т.е.
примерно с середины/второй половины 90-х в *BSD.
> Аналог "watch-файликов" был ВСЕГДА в source-based системахО, а покажи, как у тебя сейчас оформлено для (скажем) sourceforge.
>> Аналог "watch-файликов" был ВСЕГДА в source-based системах
> О, а покажи, как у тебя сейчас оформлено для (скажем) sourceforge.MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=dict/} \
ftp://ftp.dict.org/pub/dict/
>>> (заглядывая в инбокс) Прямо-таки никто? Даже до меня долетает вообще-то.
>> Ну, "караул" на уровне Инго - не кричат.
>
> Что-то не припомню сходу на том уровне майнтейнеров Debian (кроме разве kernel
> team).С разработчиком ядра логично сравнивать разработчиков ядра.
>> Не знаю что там до вас долетае...
> Например, необходимость прописывать зависимости ручками.Вы имеете ввиду в Build-Depends? Но телепатии пока не изобрели и разработчиков ходить строем с чем-то стандартным типа ./configure && make && make install - не приучили и не предвидится.
Увы, доклад не показывает пути решения данной проблемы. Даже намека.
> Я к тому, что есть огромное поле того, что люди собирают сами
> предоставляемыми сторонними инструментами. И CPAN тут -- это только верхушка
> айсберга проблемы модулей для скриптовых языков, увы. Там хоть базовая
> версия относительно одна.Я указывал правильное решение: если люди не хотят собирать сами - пусть попросят. Тех же debian-perl@. Зачем автоматически класть в дистрибутив что-то "абы было"?
>> причем подготовка пакета достаточно хорошо автоматизирована.
> Ну с тех пор как тот кромешный ужас на старом dh в
> debian/rules стал необязателен -- эту подготовку можно не называть пыточной камерой
> хотя бы ;-)Он не был и до. Существовали (и продолжают) инструменты, облегчающие подготовку первоначальной версии пакета (всякие dh_make). См. вашу же новость https://www.opennet.ru/opennews/art.shtml?num=34119
Нелишне подчеркнуть, что "проблемы" первоначальной подготовки пакета - сильно преувеличены. Это действие, которое делается один раз. Основное время мейнтейнера занимает исправление багов, тестирование, адаптация пакетов под новый релиз upstream (это и автоматизировано лучше первоначального сетапа debian/).
>> А вот зачем мейнтейнерам перл в Debian заморачиваться
>
> Полагаю, Вы к таковым не относитесь -- потому предложу за них и
> не выступать. Перловку в альте немного майнтейню, если что.Альт здесь нерелевантен, извините. А за дебиановских мейнтейнеров перла я и не выступал. Кое-кто порядком покоцал цитату из меня любимого - и убрал знак вопроса в конце.
>> Тут нужны подробности. Пока у меня складывается плохое впечатление о вашем коллеге.
> линуксовод со стажем, сишник.Да будь он хоть трижды ГСС и полный кавалер ордена Славы :)
По факту - используя тестинг он подписался на наличие потенциальных проблем. Ничего страшного, человек может быть незнаком с политиками в конкретном дистрибутиве и т.п. Но если проблемы "удивили" его на грани матерных истерик - это определенно его характеризует чуть более сурово.
>> Тестинг - это тестинг, там много чего периодически ломают.
>> Использование микса stable+testing - официально не поддерживается.
>> Наконец, nvidia-драйвер не часть Дебиан, вы уж извините.
>
> Внимание, вопрос: для каких задачи тогда пригоден Debian stable?Вопрос философский. Зачем человеку компьютер? Даже не знаю что сказать.
Читайте http://www.debian.org/News/ - там, в частности, есть и некоторые примеры применения.
>> В варианте b) - действительно, помог бы бэкпорт.
> О чём было второе внушениеНу вот и я о чем. Жаль, конечно, что ожидания человека в отношении дистрибутива не оправдались. Но согласитесь - это целиком и полностью его вина.
>> Увы, автоматизировать полностью его принципиально невозможно.
>> Причем даже "тривиальный" случаи уровня "добавили запись в debian/changelog
>> и пересобрали". Если, конечно, у вас нет развернутой автоматической системы
>> тестирования пакетов. Работы оных, а не сборки.
>
> Если нет автоматической сборки, нечего замахиваться на автоматическое тестирование (или
> автоматизацию сбора статуса -- "работает/сломано").Это почему так? Ручное тестирование кучи пакетов - оно на порядок сложнее, собственно, подготовки самой сборки (правка метаинформации, скриптов и т.п.). Особенно, для "интерактивных" программ (слыхал, что в opensuse что-то ковыряли на эту тему, но искать лень).
Так что это реально облегчило бы труд мейнтейнеров.
>> По содержимому доклада выше - так и не понял что конкретно криво в Debian.
> Рукопашный подход.Емм... А в ALT есть аналог, к примеру, puiparts? А lintian, а debcheck? Упрекать Debian в недостатке автоматизации - крайне несправедливо, имхо.
>> А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров.
> Было и сопоставимое с Debian лет десять тому, это тоже не работает.
> Собсно, перечитайте новость.Но в дебиан-то, вроде, работает?
>> Боюсь, с подходом к выпуску, тестированию и дальнейшему
>> сопровождению релизов в Debian - такое стало бы для него фатальным
>
> Не уверен. По крайней мере watch-файлики изобрели в дебиане -- стало
> быть, и те люди скорее всего предполагали, что увеличить циферку и
> попытаться собрать может и робот, а вот человеку лучше побольше времени
> оставить читать NEWS или коммиты и проверять работоспособность, освободив при возможности
> от лишней рутины.Так вот это и есть реальная автоматизация. Более того, она действительно *работает*.
>> Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org.
> Можно [ссылку на] список? Смутно припоминается, что чего-то действительно не хватало
> -- но в дебиане не припоминаю, например, реализованной в масштабах всего
> main проверки на разрешимость ELF-символов.Откройте цитированный адрес - там в вики есть обзор деятельности команды. Кое-какие из сервисов я упомянул выше.
>> Соответственно, сабж без хорошей системы автоматического тестирования -
>> приведет элементарно к дальнейшему падению качества дистрибутива.
> Проблема вкратце такова: либо релизить "when it's совсем ready" и пользоваться заслуженной
> репутацией ископаемого, либо перераспределять и подпирать _ограниченный_ ресурс человеческого
> внимания так, чтобы протекание кода из апстримов к пользователям происходило с
> минимальными накладными расходами и максимальным отловом проблем по дороге."Ископаемое" - это эмоционально и необъективно. Вот не нужно, чтобы ко мне "плавно перетек" Gnome3 из апстрима. Мне удобно работать, и я не хочу быть альфатестером сомнительных инноваций. Что касается более специфического ПО (научное, для сервера) - там мастеров-ломастеров меньше и интеграция с апстрим лучше и меньше разрыв версий, если он вообще существенный.
Вы путаете разные дистрибутивы с разными целями. Принцип "when it's ready" - относится к качеству включаемого ПО. Сдерживающим фактором обновления версий ПО здесь является количество RC багов, для которых автоматическое пакетирование новых релизов - совершенно иррелевантно.
"Быть максимально близкими к версиям upstream" - совершенно иной принцип, иная цель.
Можно ли совместить их в одном дистрибутиве? Думаю, здесь есть ресурс, который пока задействован в наименьшей степени - это собственно апстрим. Там, где он активно взаимодействует с мейнтейнерами в дистрибутиве (или сам играет эту роль) - с версиями проблем нет.
> А в ALT есть аналог, к примеру, puiparts? А lintianМиша, я уже не один с такими "странными" вопросами ;-)
У вас rpm-щиков этого похоже ни у кого нет.
В pkgsrc pkglint ну очень дотошный, и это очень удобно.
> С разработчиком ядра логично сравнивать разработчиков ядра.Минуточку, Инго вроде бы как не приводил дебиан в качестве исключения. Или я Вас совсем не понимаю.
То есть в чём проблема: _везде_ плохо. (мальчикам-прянишничикам: у ваших ещё хуже)
>>> Не знаю что там до вас долетае...
>> Например, необходимость прописывать зависимости ручками.
> Вы имеете ввиду в 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...
>> С разработчиком ядра логично сравнивать разработчиков ядра.
>
> Минуточку, Инго вроде бы как не приводил дебиан в качестве исключения.
> Или я Вас совсем не понимаю.Ну все просто.
Мнение Инго: все плохо, судьи куп^W^W!
Мнение разработчиков Debian: ничего не все, никаких фатальных караулов не кричим, работаем помаленьку. За всех, конечно, не могу расписаться - но радикально менять никто ничего не планирует.>>>> Не знаю что там до вас долетае...
>>> Например, необходимость прописывать зависимости ручками.
>> Вы имеете ввиду в Build-Depends?
>
> В том числе.Ну а ишшо-то где? В бинарных пакетах dh все давно генерит.
>> Но телепатии пока не изобрели
> Да, но http://lists.altlinux.org/pipermail/devel/2011-December/1927...Как еще один костыль для мейнтейнера (ручками пускать!) - да. И спасибки! А как часть ентой системы автоматизации сборки - сильно сомневаюсь. Ну, поживем - увидим.
>> и разработчиков ходить строем с чем-то стандартным типа ./configure && make &&
>> make install - не приучили и не предвидится.
>
> Снабжённые головой и так уже сообразили, чем "обычные" варианты лучше "необычных".
> И этих "обычных" не так уж и много.Да вот, "чисто случайно": mdadm. Свой ручной Makefile. Другой пример - ядро Linux. Тоже не последний проект (хотя его вы можете забраковать в "обычные" в силу значимости).
Кстати, сколько "обычных" - на вашу оценку?
>> Зачем автоматически класть в дистрибутив что-то "абы было"?
>
> Не "абы было", а "с минимальными усилиями, как только понадобится". Статистику
> на http://www.debian.org/devel/wnpp/ наверняка же видели -- там далеко не нули.А надо класть не "когда понадобится", а когда это на это что-то найдется мейнтейнер. Вот потому и не нули. Собрать пакет - это только самый первый и простой шаг.
> Кому как, для меня это был один из существенных доводов держаться от
> самой мысли о поддержке пакетов в дебиане как можно дальше.
> Потому как совершенно безумное дублирование болванки без какой бы то ни
> было необходимостиЕсли необходимости не было - дублировать не следовало. Требуемые цели в debian/rules очень ограничены числом. И вовсе не обязательно вам было в каждой лишние вызовы dh_* копипастить ;)
> Совершенно позорное для дебиана место и непонятно, как оно столько прожило.
Policy. И никуда оно не делось - требования к debian/rules остались прежними (и простыми), а debhelper/cdbs - остались опциональными.
> PS: ещё один пруфлинк как раз в руки пришёл: http://projects.deepnet.cx/trac/debbuild
$ apt-cache search debbuild
$Упс. Еще один никому не нужный бедный хомячок...
>> Нелишне подчеркнуть, что "проблемы" первоначальной подготовки пакета -
>> сильно преувеличены.
>
> Можно поинтересоваться, сколько пакетов Вы первоначально подготовили?Немного: ~10-20. Если считать только публичные (т.е. в архиве). Пакеты разные - есть и сервисы, и библиотеки, и модули (python, octave; guile :D), и всякий ******* на perl/php.
>> Основное время мейнтейнера занимает
> Это всё очень сильно зависит от того, насколько сложен/устоялся упаковываемый.debian/copyright, по моему опыту - требует наиболее фундаментальных усилий :)
>>> Внимание, вопрос: для каких задач тогда пригоден Debian stable?
>> Вопрос философский. Зачем человеку компьютер? Даже не знаю что сказать.
>
> Вот и я не очень понимаю, хотя теоретически несколько use cases и представляюДа сколько угодно. Десктоп (от разработчика ядра до домохозяйки), хостинговый сервер, вычислительный кластер...
> К сожалению, безумная свистопляска с железом очень сильно бьёт по возможности стабилизации
> софта и соответственно применимости таких выпусков на доступном оборудовании.Какая свистопляска? Сервера живут года по три - как минимум. Да и рабочие станции не меньше.
В тяжелых случаях есть бакпорты. А вообще - это на совести железячников, если они поддерживают только HEAD релиз в mainline. Либо это уйдет и драйвера будут, наконец, клепать и для стабильных веток - либо ежики будут и дальше есть кактус. Ну или из области фантастики: гора двинется к Магомету и начнет когда-нибудь блюсти совместимость хоть на уровне API.
>> Жаль, конечно, что ожидания человека в отношении дистрибутива не оправдались.
>
> Да ладно, это всё про выводы. Хотя также и на заметку
> тем, кто на всякий чих будет советовать Debian testing и говорить,
> мол, сам сижу и всё хорошо. Т.е. хоть предупреждайте, что
> тогда надо отслеживать...Предупреждение висит здесь:
http://www.debian.org/releases/
http://www.debian.org/doc/manuals/debian-faq/ch-choosing.en....Хотя, перед squeeze я имел привычку ставить testing "дома", дабы освоиться пораньше и багов порепортить.
>>> Если нет автоматической сборки, нечего замахиваться на автоматическое тестирование
>> Это почему так? Ручное тестирование кучи пакетов - оно на порядок сложнее,
>> собственно, подготовки самой сборки (правка метаинформации, скриптов и т.п.).
>
> Вот ровно потому, что автоматизация тестирования ещё сложнее.Зато и нужнее, как я пытался выше представить :)
>> Что касается более специфического ПО (научное, для сервера) -
>> там мастеров-ломастеров меньше и интеграция с апстрим лучше
> Ой, вот давайте только без сказок про научное ПО. Типичный случай
> как раз обратный, увы -- принцип "работает на моей машине" из
> всех щелей :(Ну, не знаю что у вас было за "научное". Может из категории "образовательное", скорее? Клеветать на python-numpy, octave, gsl, openmpi и т.п. - я подобным образом не стал бы. Речь шла именно о ПО такого рода.
>> Принцип "when it's ready" - относится к качеству включаемого ПО. Сдерживающим
>> фактором обновления версий ПО здесь является количество RC багов, для которых
>> автоматическое пакетирование новых релизов - совершенно иррелевантно.
>
> Если такой баг -- апстримный, то может быть и релевантно. При
> обеспечении возможности протестировать "сборку сбоку".Ну, "апстримный" баг - это же такой эвфемизм: "у нас руки не дошли поправить, кастуем в тему афтора". Апстримный или нет - тупой перепаковкой нового релиза проблемы в Debian решать не принято. Так будет только очередной глюкодром: один баг исправили - десять новых сочинили.
>> "Быть максимально близкими к версиям upstream" - совершенно иной принцип, иная цель.
>
> Это заодно принцип минимизации форка. Хорошо сочетается с предыдущим тогда, когда
> апстрим понимает, поддерживает и реализует подход со стабильными ветками (хотя бы
> одной, лучше двумя).Если глюкодром апстрим не интересен - рано или поздно стабильными ветками он заинтересуется. А нехорошие вещи лучше не поощрять.
> Ну все просто.В следующей серии кто-нить явно вспомнит бронепоезд...
>>> Вы имеете ввиду в Build-Depends?
>> В том числе.
> Ну а ишшо-то где? В бинарных пакетах dh все давно генерит.Это радует ;-)
> Кстати, сколько "обычных" - на вашу оценку?
Три штуки. (прячась в заранее откопанную траншею от праведного белорусского гнева)
> А надо класть не "когда понадобится", а когда это на это что-то найдется мейнтейнер.
> Вот потому и не нули. Собрать пакет - это только самый первый и простой шаг.Верите ль, я в курсе.
> И вовсе не обязательно вам было в каждой лишние вызовы dh_* копипастить ;)
Да мне-то что, это dh и шаблоны такие.
> Упс. Еще один никому не нужный бедный хомячок...
Вы вот зря с таким attitude.
>> Можно поинтересоваться, сколько пакетов Вы первоначально подготовили?
> Немного: ~10-20. Если считать только публичные (т.е. в архиве).Спасибо.
>> Вот и я не очень понимаю, хотя теоретически несколько use cases и представляю
> Да сколько угодно. Десктоп (от разработчика ядра до домохозяйки),С трудом, но верю (скорее последнее, чем первое).
> хостинговый сервер,
Опять же с некоторым трудом.
> вычислительный кластер...
А вот тут не припоминаю вовсе, хотя наверняка всё-таки есть. И даже есть предположение, почему так.
>> К сожалению, безумная свистопляска с железом
> Какая свистопляска?С выпуском железа, не живущего на имеющихся драйверах добавлением PCI ID-шек.
> В тяжелых случаях есть бакпорты.
Мало того, я и на серверах что-то не припоминаю дебианов с ядрами не из бэкпортов. Не расспрашивал (а надо бы), но.
> Хотя, перед squeeze я имел привычку ставить testing "дома", дабы освоиться пораньше
> и багов порепортить.Аналогично :)
> не знаю что у вас было за "научное". Может из категории "образовательное", скорее?
Именно жёстко-научное...
> Клеветать на python-numpy, octave, gsl, openmpi и т.п. - я подобным образом
> не стал бы. Речь шла именно о ПО такого рода.Это скорее "общее", чем именно "научное". Соответственно при более разностороннем интересе шансы на совместное допинывание до формы шара куда выше, чем при "мне тут посчитать".
>> При обеспечении возможности протестировать "сборку сбоку".
> Так будет только очередной глюкодром: один баг исправили - десять новых сочинили.Ключевое слово -- "возможности".
> А нехорошие вещи лучше не поощрять.
Эт да.
>> Кстати, сколько "обычных" - на вашу оценку?
> Три штуки. (прячась в заранее откопанную траншею от праведного белорусского гнева)Буу. Считайте гнев интернациональным.
Считаем: 1) ./configure && make 2) cmake 3) scons 4) pecl 5) octave pkg 6) python eggs 7) модули ядра 8) Makefile.pl 9) RubyGems 10) модули апача.
Каждый пример подобного "обычного" сценария конфигурации-сборки-инсталляции - десятки или сотни пакетов в Debian. Каждый интерпретируемый язык, каждая система с dso-плагинами - имеет что-то свое, уникальное.
>> И вовсе не обязательно вам было в каждой лишние вызовы dh_* копипастить ;)
> Да мне-то что, это dh и шаблоны такие.Шаблоны можно и нужно редактировать.
>> Упс. Еще один никому не нужный бедный хомячок...
> Вы вот зря с таким attitude.Если это было бы кому-то в Debian надо - было бы в архиве. Все честно.
>> вычислительный кластер...
> А вот тут не припоминаю вовсе, хотя наверняка всё-таки есть. И
> даже есть предположение, почему так.Примеры есть даже в цитированных выше новостях. В Европе Debian любят, так что "таки есть".
> Мало того, я и на серверах что-то не припоминаю дебианов с ядрами
> не из бэкпортов. Не расспрашивал (а надо бы), но.Ну, у меня нет на данный момент ни одного с бекпортами. Например.
>> не знаю что у вас было за "научное". Может из категории "образовательное", скорее?
> Именно жёстко-научное...Настолько, что стыдно упомянуть героев?
>> Клеветать на python-numpy, octave, gsl, openmpi и т.п. - я подобным образом
>> не стал бы. Речь шла именно о ПО такого рода.
>
> Это скорее "общее", чем именно "научное".Это "научное" того уровня, что кладут в дистрибутивы.
> Считаем: 1) ./configure && make 2) cmake 3) sconsДа, причём третий уже с натяжкой.
> 4) pecl 5) octave pkg 6) python eggs 7) модули ядра 8) Makefile.pl 9)
> RubyGems 10) модули апача.А это всё уже проектоспецифичное (местами даже проще).
>>> не знаю что у вас было за "научное". Может из категории "образовательное", скорее?
>> Именно жёстко-научное...
> Настолько, что стыдно упомянуть героев?Да если б сходу помнил (пора уж записывать таковых). Можете честно сказать "а, ну ясно" -- но просто стараюсь получше руки мыть от такого софта :(
>> Считаем: 1) ./configure && make 2) cmake 3) scons
> Да, причём третий уже с натяжкой.Ну, гранатами вам не зря грозили...
>> 4) pecl 5) octave pkg 6) python eggs 7) модули ядра 8) Makefile.pl 9)
>> RubyGems 10) модули апача.
>
> А это всё уже проектоспецифичное (местами даже проще).Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан. Если уж вы *это* игнорируете...
>>>> не знаю что у вас было за "научное". Может из категории "образовательное", скорее?
>>> Именно жёстко-научное...
>> Настолько, что стыдно упомянуть героев?
>
> Да если б сходу помнил (пора уж записывать таковых). Можете честно
> сказать "а, ну ясно" -- но просто стараюсь получше руки мыть
> от такого софта :(Тогда вам лучше, наверно, отозвать свою критику.
> Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан.
> Если уж вы *это* игнорируете...Да не игнорирую, а с таким несколько проще, если только не забыли при создании положить нужные метаданные (как в своё время с гемсами). Вариативность меньше.
> Тогда вам лучше, наверно, отозвать свою критику.
Скорее "оставить при себе". Отзывать не буду, кошмарные исходники от того не пропадут.
IIRC тот же WIEN2K тоже не подарок.
>> Это проектоспецифичное занимает, по скромным оценкам, больше половины репов дебиан.
>> Если уж вы *это* игнорируете...
> Да не игнорирую, а с таким несколько прощеМожет и проще. Но это совершенно разные системы сборки. Причем, поддержка одной даст немного для другой.
> IIRC тот же WIEN2K тоже не подарок.
Это вообще пропиетарное ПО.
Я не знаком с ним, к сложалению, предметно. Можно какие-то подробности? Гугл заставляет меня верить, что данное ПО работает чуть больше чем на одной машине разработчика ;)
>> IIRC тот же WIEN2K тоже не подарок.
> Это вообще проп[р]иетарное ПО.Ага.
> Я не знаком с ним, к сложалению, предметно. Можно какие-то подробности?
Можно поискать по запискам, что с ним приходилось делать -- но это был относительно недавний пример всё тех же старых ощущений: "чем эти люди думали и писали"...
Впрочем, долгого и нудного ругания явно не стоит.
>> Кстати, сколько "обычных" - на вашу оценку?
> Три штуки. (прячась в заранее откопанную траншею от праведного белорусского гнева)Я все слышу, и граната уже летит :-)
>> и разработчиков ходить строем с чем-то стандартным типа ./configure && make &&
>> make install - не приучили и не предвидится.
> Снабжённые головой и так уже сообразили, чем "обычные" варианты лучше "необычных".
> И этих "обычных" не так уж и много.- Эй, мужик!
- А!
- Ну ты в курсе.
а и правильно тамблвид и база меняющаяся раз в год это хорошо.
Буду предзаказывать в их Интернет-магазине двуслойный DVD с openSUSE, чтобы поддержать их деньгами.
Почтой России в Задрипански всякие доставляют? Я б тоже купил.
Главное, чтоб чертов яст подхватывал чертовы темы чертовых кед, из коробки. Ну и чтобы сеть не ломали. Так победим! ))
Выпускать пора, а они все еще планы о планах по плану выпуска утрясают
Удачи разработчикам, но пока не сделают из сюси нормальный дистрибутив - с федоры не слезу! :)
Сусе не такой плохой дистр как тут многие говорят. Я много узнал и научился пользуясь сусе, и с этим дистром у меня возникало меньше проблем чем с остальными. Но я реально не понимаю почему разрабы рвутся работать именно по этой модели выпусков релизов. Если эта попытка держать себя в узде и не давать слабинку... то мы видим результат. Разрабы сусе уже не первые кто работают по этой системе и как правило не всегда удачно, так что не понимаю почему им нравиться наступать на те же грабли.