From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4001F0F3.6010802@l14.ru> Date: Mon, 12 Jan 2004 03:57:23 +0300 From: Alexey Lubimov User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.3) Gecko/20030331 X-Accept-Language: ru, ru-ru MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] Re: .a vs .so References: <20040108160330.GA6208@nomad.office.altlinux.org> <20040108161404.GN2244@pyro.hopawar.private.net> <20040108201457.GA28535@nomad.office.altlinux.org> <20040110222311.GB16686@mhz.mikhail.zabaluev.name> <20040111022329.GD12307@localhost.localdomain> <4001614E.20808@l14.ru> <20040111160122.GA18161@nomad.office.altlinux.org> <4001807E.2040602@l14.ru> <20040111181039.GA18232@nomad.office.altlinux.org> <4001CC66.60004@l14.ru> <20040111230846.GA19026@nomad.office.altlinux.org> In-Reply-To: <20040111230846.GA19026@nomad.office.altlinux.org> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 00:57:25 -0000 Archived-At: List-Archive: List-Post: Dmitry V. Levin пишет: >>При операции релиза (типа sandcl endpocket sisyphus) репозитария можно >>хоть полдня ползать по репозитарию скриптами, раскрывая цепочки >>зависимостей (buildrequires - они железные и проверены в bte) пакетов и >>проверяя получившийся ряд на смешивание в них запрещеных сочетаний libdb. > > > Это всё замечательно и можно применить прямо сейчас к текущему Сизифу, но > в результате этой технически непростой работы можно будет лишь > констатировать несовместимость. Это само по себе хорошо, но работы по > исправлению пакетов при этом меньше не станет. Не совсем так. Это должна быть в большинстве своем автоматическая работа. Кладем новую библиотеку (руками и быстро), пересобираем репозитарий (автомат и долго) и выясняем две цифры - количество непересобранного и количество собранного неправильно. Если результат приемлим (ручная работа по правилам головой) - второй этап - тестирование в дедалусе (общественность и майнтейнеры). получили подтверждение работоспособности - в сизиф (общественность). > > Собственно говоря, это ответ на другой вопрос. > > >>>Как вы сможете отличить случайную линковку от неслучайной? >> >>Никак. Это как в случае с мотоциклами. Сначала удаляют "лишний метал" со >>ступицы, а потом теряют тормоза от перегрева. >> >>Чтобы определить случайность линковки в общем случае, надо >>протестировать программу по полной программе. Имхо, сизиф страдает от >>таких "оптимизаций" поболее, чем от их отсутствия. > > > Это как (протестировать программу по полной программе)? Для библиотеки либо прогнать тесткейсы на все случаи ее использования либо протестировать все программы, ее использующие. Для программ - прогнать все функции и убедится, что все работает так, как предполагается. Таких возможностей все равно нет. Стало быть надо быть поскромнее в своем стремлении вмешаться в процесс сборки программы и уйти с общего для всех пользователей софтины тест-пространства. >>У программ есть авторы и они обычно пишут список зависимостей. Далее >>второе (расширяющее) приближение - сборка. На этом все начные методы >>заканчиваются иначинается либо гадание либо тупая ручная статистика >>учета возникших от оптимизации проблем. > > > Это очень оптимистичная оценка maintainer'ов, которые на самом деле очень > занятые и ленивые люди. Не для всех пересобрать пакет раз в месяц > является выполнимой задачей. Это надо иметь в виду. Я говорил про авторов, а не про майнтейнеров. Автор разбирается в том, что он написал и имеет фидбек поболее майнтейнера отдельно взятого альтлинукса. > >>Есть БТЕ. Вот пусть он и отсекает 100% лишнее. Остальное в сизифе просто >>не реализуемо в принципе. > > > Значит, надо искать другие приёмы. Пока что это означает закрытие дистров от расширений и выдавливание самих себя на обочину. Осталось зарезать libtool с тем, чтобы вообще ничего несизифного не собиралось и задача бужет выполнена. > > >>>Есть, конечно, некоторые приёмы, которые позволяют определить, >>>используется ли данной программой/библиотекой данная библиотека напрямую. >> >>ldd? >>имхо не слишком надежно. > > > Конечно, это всего лишь warning, т.е. hint, если хотите. > в логи, в логи хинты. как и потерянные в RPM_BUILD_ROOT файлы, а за потерянный там *.pc можно и error выкатить Конечно, диагностики всегда мало. :) >>>>Рекурсивно разворачивать во время сборки все связи и завершать сборку >>>>при конфликте версий через другие линкуемые библиотеки имхо совсем >>>>другая задача. не так? >>> >>>Это не задача, это приём, который имеет смысл применить, хотя он и не >>>может выявить всё, например, проблемы, возникающие при динамической >>>загрузке модулей. >>> >>>Предложите, как лучше оформить интерфейс: как описать множество >>>конфликтующих библиотек (которое будет меняться), как включать/выключать >>>эту проверку при сборке того или иного пакета. >> >>Я вижу это таким образом. >> >>Должна быть практически не меняющаяся по именам умолчальная среда с >>одним претендентом по каждой альтернативе. >>один gcc, glibc, libpng, libdb4 etc > > > Я вообще-то не об этом спрашивал. Возможно. Если вы хотите сразу код, то по моему, до него еще дожить надо. >>Альтернативы должны имет звания gcc-compat2.96 glibc-compat2.3 >>libng-compat2 libdb5-compat0 etc >> >>Замечу, что основные имена являются скользящими. То есть libpng когда то >>было версии 2, а потом без изменения имени становится версии3, а вот >>-compat уже ссылаются на определенную версию и заморожены в таком >>состоянии. >> >>пакеты в нормальном состоянии должны требовать в BuildRequires gcc, >>glibc, libpng, libdb4. >> >>Если пакет перестает собираться с новой версией и начинает требовать >>-compat, то в BuildRequires вручную ставится зависимость на конкретный >>compat. >> >>Зависимость на -compat и является признаком замороженного на версии пакета. > > > Если опустить этот -compat, то именно так сейчас и происходит в Сизифе. не совсем. Я должен в зависимостях указывать libqt3, libpng3, libdb4.1 А тут я в большинстве случаев указываю libpng libdb4 , а подставляется дефолтная версия. Таким образом можно склонить большинство пакетов к одной версии либы и выделить действительно неработающие compat-требующие пакеты. Правда, не уверен, что это осуществимо... > >>Пишуться правила типа libdb conflicts libdb-compat >> >>При пересборке факт смешанного использования библиотек через третью >>программ не ловится. Его даже и ловить не надо. >> >>После пересборки репозитария, по нему запускается скрипт проверки, >>рекурсивно разворачивает зависимости и по правилам ловит факт смешивания >>конфоиктующих альтернатив. После этого майнтейнеры решают, что делать. >>То ли выбросить что либо из репозитария, то ли пересобрать по другому. > > > Можно и так ловить. пока не ловится и тем более не ловится автоматом. > > Но исправлять-то придётся, и не факт, что это будет просто сделать, если > одна из зависимостей наведённая. Ну так наведеных зависимостей должен быть минимум. Для того в чрут и загоняем. вот, к примеру, wine ис сизифа тащит за собой пол кде. пересборка без кде либ полностью очищает его от зависимостей на них. > Противоречие только в предлагаемых подходах к разруливанию. Во всём > остальном - полное взаимопонимание. :) ну и славно. :) > > >>>>Ни разу. Просто в спецслучаях указывать из нескольких альтенатив >>>>(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие >>>>конкурентов. >>> >>>Что такое спецслучаи и кто будет их отлавливать? случаи, когда в репозитарии есть одновременно несколько одинаковых библиотек разных версий. Их даже по имени можно узнать. У них версия в нем сидит. майнтейнер будет отлавливать по факту несборки или неработы с текущей версией библиотеки. С этой версией не получилось - попробовать с другой. Получилось - либо портировать, либо так оставить, если никому это не надо. Все как и сегодня, только диагностики больше и автоматизма. >> >>майнтейнер. прога то либо не будет собираться, либо работать. >> >> >>>Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно >>>разные libdb4.X? А если это невозможно? >> >>В бте? >>такие случаи автоматом не решаются. Придется собирать консилиум >>майнтейнеров и решать, кого убрать. Как сегодня и происходит. >> Да, только сегодня убирают из репозитария, а я предлагаю убирать из БТЕ. Для этого консилиум не нужен. Он нужен только в случае совместного использования либы между собой и через себя. И только между заинтересованными майнтейнерами. А арбитр - проверка репозитария на выпавшие пакеты. >> >>>>По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь >>>>есть? >>> >>>Есть и будет появляться новое всегда, когда у библиотеки меняется soname. >> >>Не так. Это когда библиотеки обновляюти вместе с тем под другим именем >>оставляют старые версии. Если библиотеки просто обновляют, то либо прога >>собирается с ней, либо нет, но левых зависимостей все равно не возникает. > > > Если у библиотеки достаточно разных пользователей, то её нельзя "просто" > обновить, не сохранив прежнюю альтернативу. Сколько времени она будет > жить, в каждом конкретном случае бывает по-разному. > Ну не надо скромничать. В свое время libgnomeprint(ui) 2.0 молча задавили, хотя она даже не мешала версии 2.2. glabels, помнится тогда автоматом улетела и еще несколько неплохих программ... Собственно, спецслучай от количества не перестает быть спецслучаем. Если есть несколько версий библиотеки - майнтейнер должен либо ничего не выбирать и тогда должна ставится текущая дефолтная либа, либо честно выбрать соответствующий -compat.