Кто-нибудь пользуется paludis'ом?

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

пока апстрим думает либо маскируем либо патчим

А если апстрим НЕ собирается ничего фиксить, а объем патчей, которые нужно написать самому тянет на полноценный форк, тогда что? Напоминаю, пакет может быть интересен для поддержки, но никак ни для разработки - такая позиция понятна, я надеюсь меня в ней никто не собирается обвинять?

То есть исправить пару багов в сборке и пару сегфолтов - ОК. Написать кучу новых фич или переписать с нуля - не ОК.

И да, побуду кэпом. Гента - это в первую очередь свобода выбора. Главное дерево портажей - это некий эталон, который должен работать в любых поддерживаемых конфигурациях. Если он не работает или качество его работы хреновое(а это самое качество складывается из ебилдов внутри этого дерева) - это повод для серьезного беспокойства. Дальше - оверлеи, в частности sunrise, но для примера подойдет и любой другой оверлей с любой мыслимой(и немыслимой) QA policy(или с отсутствием таковой), которую только можно представить. В них могут быть пакеты, по какой-то причине не принятые в главное дерево. Это и тематические, и персональные оверлеи. И работать надо в сторону помещения пакета хотя бы в тот оверлей, который имеет поддержку со сторону разработчиков Gentoo(sunrise или тематические оверлеи гентушных проектов) или оверлей инициативного пользователя(пользователей), который жизненно заинтересован в работе пакета(например, stuff) и способен поддерживать его хотя бы в рабочем состоянии.

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

Гента - это в первую очередь свобода выбора.

ооооо, зря ты поднял эту тему :3
ща я тебе расскажу историю про свободу выбора:
и так, опять хромиум.
было несколько версий, которые требовали пульс железно
дал патчи - апстрим не примет, потому иди нахер
ок
потом несколько версий требовали так же железно капс
дал патчи -...ну ты понел
и это в то время, когда используется кучка гентушных патчей
где тут свобода выбора?
опять одна левая пятка
повторяю - хватит нести херню!

какого хера в том же хромиуме уже ооооочень давно используется куча патчей?

Поинтерейся у chromium team, какие из патчей они отправили в апстрим. Если никакие - возьми и отправь, заодно скажи им что они не очень хорошие люди >_<

короче - хватит оправдывать дебилов, они от этого нормальными не станут

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

скажи им что они не очень хорошие люди >_<

это они уже знают :3

дал патчи - апстрим не примет, потому иди нахер

ссылку на переписку можно?

не с той стороны ты посмотрел
ты принял за правило желание левой пятки
поставил во главу и поклоняешься
в этом треде ты меня окончательно в этом убедил

давно потёрто
ибо зачем хранить переписку с дебилами?

Фух, я просто выслушал аргументы другой стороны. И я никого не оправдываю. Я принял их к сведению. Я тебе могу рассказать эпичное действо с проталкиванием нового net-analyzer/fragroute в дерево, как мне пришлось знатно поплясать с бубном, чтобы его не выпилили. Я знаешь ли тоже был недоволен >_<

ты мне лучше скажи, ты эти патчи в stuff-е держишь? Если да - я попробую поговорить с chromium team

кстати, если угодно, моя пятиминутка ненависти - docs-team не использует статус CONFIRMED и IN_PROGRESS в своих багах. Либо UNCONFIRMED, либо RESOLVED. Поубивал бы >_<

они давно стали не нужны - апстрим сделал потом как надо

1. Не все имеют возможность стать разработчиком любого понравившегося проекта и пофиксить его.

Если ты пользователь, да - увы, это проблема. Если ты разработчик - форк - решение проблемы в случаях мертвого или несговорчивого апстрима. Делать git merge/rebase(или подобные действия для других VCS) в случае небольших изменений не так уж и сложно(а вот для больших - это дааа, это жопоболь).

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

Скажу честно, то что я сказал по добавлению проприетарщины в дерево - это чисто моё видение ситуации, возможно настоящее положение дел отличается. Хотя наличие ключей а-ля QA_PREBUILT в ебилдах как бы намекает на то, что QA team в случае блобов просто ничего сделать увы не может, поэтому такие ебилды имеют менее пристальное внимае QA team. Скорее всего позиция такая же, как и с багзиллой ядра Linux - некоторые баги тупо закрывали из-за проприетарного модуля nvidia на десктопе у пользователя, когда выясняли что проблема в блобе. Причина CANTFIX в данном случае самая верная.

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

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

Проект вычищают из дерева treecleaners, если на него есть дохрена открытых багов и он не работает как надо. Или устарел и заменен другим. В остальных случаях - я могу привести примеры утилит категории net-analyzer/ апстрим которых по 5-6 лет мертв. Но они просто работают - следовательно нет причин их удалять.

Гента - это в первую очередь свобода выбора.

Гы, ссылку как я на ЛОРе постил мегабаксу опровержение этого от одного из дженту тимы(it's about POWAHH!!) я сейчас что-то не найду, но достаточно погуглить «gentoo is not about choice» =)

Нашел. Ну что могу сказать, для меня гибкость - это и есть выбор. Просто мы с nightmorph'ом по разному понимаем выбор видать :-D

а вообще нашу с тобой беседу, да перевести бы на человеческий английский, да запостить где-нибудь и ссылкой ткнуть остальных девов - «кто что думает на этот счет?». Но увы, я литературно это перевести не осилю :-(((

и я, и я того же мнения/умения (

Я поговорил с автором LeechCraft, выяснил, что он не против динамической линковки, а тот предупредил меня о том, что апстрим qxmpp сказали линковаться только статически. Дальше - смотри баг

там другая ситуация. в deadbeef тоже очень просто сделать, чтобы он линковался динамически с либами из репов. проблема в том, что deadbeef на уровне исходников с ними не совместим. и это не потому, что я по своей прихоти поломал совместимость. просто библиотеки пришлось существенно расширять, чтобы получить необходимый уровень качества/работоспособности. некоторые расширения ломают API. ничего кроме мержа в апстрим с этим не поделать. даже если смержить в апстрим измененных библиотек (а это врядли удастся) — получится ситуация, что в большинство дистров новая версия библиотеки прилетит через год-два. это слишком сложно и долго.

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

т.е., мне достаточно форкнуть GPL, и все получится?

эти либо только говядина и использует
и лежат они в его собственной дире

справедливости ради, за такое надо бить по рукам долго и больно, и делать резекцию ЧСВ.

тоже внутри тащат все зависимости, в статически слинкованном виде

обновил скайп - обновил автоматом и дырявую либу, с которой он слинкован.

right now, deadbeef source tree contains forks of 16 different libraries, and won't even compile against upstream versions

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

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

сорри, но на этом предложении сломался парсер.

upd: а, все, дошло. впилить в свой - это значит бандлить в своем тарболле? так я это и сделал.

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

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

обновил скайп - обновил автоматом и дырявую либу, с которой он слинкован.

я как бы об том и написал, что несмотря на это — скайп, флеш и прочие блобы есть в портежах и прочих репах. а опенсорс с бандленными либами не пускают.

справедливости ради, за такое надо бить по рукам долго и больно, и делать резекцию ЧСВ.

еще один специалист, млять, учить пришел.

а вообще нашу с тобой беседу, да перевести бы на человеческий английский, да запостить где-нибудь и ссылкой ткнуть остальных девов - «кто что думает на этот счет?». Но увы, я литературно это перевести не осилю :-(((

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

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

я выше упоминал про ключи а-ля --disable-internal-lib для использования внешних библиотек?

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

я выше упоминал про ключи а-ля --disable-internal-lib для использования внешних библиотек?

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

Фух. Еще раз, по шагам объясню ход моей мысли:

1) выкладывание тарболла каждой форкнутой тобой либы, из тарболла самого deadbeef ничего не удаляем;
2) публикация где-нибудь ссылок на эти тарболлы;
3) добавление ключей --disable-internal-lib на каждую либу, по умолчанию - юзаем встроенные;
4) Опционально: добавляем в README инфу о том, что используются форкнутые либы(чтобы кто-нибудь не пробовал собирать с оригинальными)
5) PROFIT!

Поясню. В генте один и тот же пакет вполне себе может ставить библиотеки с разным ABI. Если все зависимости предусмотреть правильно - проблем не будет.

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

ты понимаешь разницу между простой копией и форком? так вот, бандленные либы в deadbeef — форки. только без переименования. в каждой из них в README написано, что это модификация. невозможно использовать системные. они другие — у них API другой, баги другие, фичи другие. что неясно-то?

Смотри пост выше. Кто сказал что эти либы нельзя поставить параллельно, допустим переименовав имя библиотеки и соответствующие пути для заголовочных файлов и т.д.? Ведь, как ты сам сказал - «у них API другой» - по сути это уже ДРУГИЕ либы. :-D

ход мысли понятен. непонятно зачем весь этот гимор. назови хоть одну причину зачем все это делать.

Причина №1: http://blog.flameeyes.eu/2009/01/bundling-libraries-for-despair-and-insecurity

Начинать можешь с

Thirdly, more worrisome, is when the library is modified, slightly or heavily, after bundling...

После этого уже НАМ, как мэйнтэйнерам предстоит много работы. В том числе, если предстоит еще какое-то взаимодействие с тобой, как с апстримом. Но это уже сдвиг с мертвой точки...

почему нельзя просто считать за данность, что данные библиотеки — часть 1 проекта, и никак иначе?

Давай начнем с простых 2 вопросов:

1) Есть ли в этом перечне библиотеки с живым апстримом, который просто не хочет принимать изменения, т.к. они ломают API, не нравятся апстриму или еще по какой причине?

2) Если библиотеки из 1 пункта присутствуют - ты их собираешься обновлять, если выйдут какие-то патчи на них? Если библиотек из вопроса №1 нет(апстрим у всех их мертв) - ты точно уверен, что больше ну никому они никогда не понадобятся ни в каком другом проекте?

И да, просто - не всегда значит «правильно». В посте по ссылке объясняется история с java, libX11 и libxcb и то как там эпически всё сломалось из-за вложенных библиотек

1) Есть ли в этом перечне библиотеки с живым апстримом, который просто не хочет принимать изменения, т.к. они ломают API, не нравятся апстриму или еще по какой причине?

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

Если библиотеки из 1 пункта присутствуют - ты их собираешься обновлять, если выйдут какие-то патчи на них?

я регулярно синхронизируюсь с апстримом, если это возможно.

ты точно уверен, что больше ну никому они никогда не понадобятся ни в каком другом проекте?

почему меня это должно волновать?

И да, просто - не всегда значит «правильно». В посте по ссылке объясняется история с java, libX11 и libxcb и то как там эпически всё сломалось из-за вложенных библиотек

не помню такой проблемы с жабой, видимо не застал. зато опенсорс и без этого ломается на зависть любой проприетарщине. обновил 1 кривую либу в системе - и все приложения ее использующие поломались.

я регулярно синхронизируюсь с апстримом, если это возможно.

Тем лучше - тебе будет вообще почет и уважение если ты будешь предоставлять diff-ы своих изменений на эти библиотеки(как это будет - отдельная ветка в форкнутом репозитарии или просто файл с патчем - дело исключительно твоего вкуса)...

почему меня это должно волновать?

If you look at the way nmap bundles libdnet, you can see that they not only document all the changes they made to the library, but also provides splitted down and commented patches for the various changes, making it possible to adapt it to their need.

Судя по всему такую позицию QA считает допустимой

Заметь, в данном случае всё сломалось именно из-за позиции, подобной твоей. То есть, казалось, бы, вложенные библиотеки должны спасти пользователей от слома ABI, а вот, не вышло...

Судя по всему такую позицию QA считает допустимой

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

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

казалось, бы, вложенные библиотеки должны спасти пользователей от слома ABI

надо было xlib бандлить — и не было бы проблемы.

ты ж сам понимаешь, что практически нереально предусмотреть вариант, что вместо xlib подсунут другую либу с тем же API, с тем же названием libX11.so.6, но которая будет функционировать не так как xlib.

Мы возвращаемся к вопросу что лучше - статическая или динамическая линковка? Давай не будем начинать этот разговор еще раз, я не в настроении, да и мы пришли к кое-каким взаимным выводам в результате прошлого диалога

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

Ведь если это никому не будет нужно - зачем же что-то делать самому? ;-)

ps. и кстати, если прочитаешь внимательно - поломали там не xlib ABI, а просто код. примерно как в glibc оптимизировали memcpy, и сломали flash. и проблема была именно в том, что новый xlib (xcb) стал несовместим со старым libXinerama, хотя ABI не меняли.

Именно. А вскрылось это потому что libXinerama должен был браться из системы(как предполагали разработчики Xorg и предполагают 90% других разработчиков), а получилось... как получилось :-)

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

ты слабо представляешь себе сколько времени занимает создание и поддержка даже 1 форка. а тут их придется содержать как минимум десяток.

в данном случае, надо было фиксить xcb, а не libxinerama. это называется обратная совместимость. правда, в мире оперсорс мало кто знаком с этим понятием.

это значит бандлить в своем тарболле? так я это и сделал.

это значит скопипастить нужные куски кода либы в свой основной исходник.