Компания Роса представила (http://www.rosalab.ru/blogs/package-changes-analyzer-pkgdiff) утилиту pkgdiff (http://pkgdiff.github.com/pkgdiff/), предназначенную для анализа различий между несколькими версиями пакета (RPM, DEB, TAR.GZ и т.п.). Pkgdiff позволяет упростить задачу по оценке внесённых в пакет изменений, на основании сопоставления содержимого пакета и метаданных. Поддерживается формирование наглядных отчётов (пример 1 (http://pkgdiff.github.com/pkgdiff/pkgdiff_reports/gstreamer/...), пример 2 (http://pkgdiff.github.com/pkgdiff/pkgdiff_reports/libqb/0.4....)), имеющих несколько уровней детализации: от вывода списка различающихся файлов и изменений структуры пакета, до детальных построчных различий отдельных файлов. Дополнительно проводится анализ изменений с учетом типа файла, например, для библиотек оценивается изменение ABI. Код утилиты написан на языке Perl и распространяется под лицензией GPL.URL: http://www.rosalab.ru/blogs/package-changes-analyzer-pkgdiff
Новость: http://www.opennet.me/opennews/art.shtml?num=32970
очень приятная софтина
Допустим, пробежаться по контенту source файлов диффом оптом мы можем сами (не касаясь формата "отчетов"), однако только ради этого можно было тулзу написать: "Дополнительно проводится анализ изменений с учетом типа файла, например, для библиотек оценивается изменение ABI."
> Допустим, пробежаться по контенту source файлов диффом оптом мы можем самиДля этого не обязательно бегать самим - достаточно заставить побегать готовые утилиты (debdiff, думаю для rpm-ок тоже что-то найдется).
> Дополнительно проводится анализ изменений с учетом типа файла, например, для библиотек оценивается изменение ABI
На этом "например" и заканчивается все оригинальное. И только ради этого стоило городить трехколесный велосипед, вместо развития существующих утилит?
Соответствующих? Развития? И какой инструмент следует развивать (надеюсь не libreoffice какой-нибудь)? (дайте ссылку на проект)
Дал выше.
Ааа, вы про debdiff и подобные для других систем. Ну а если нужна одна утилита которая будет объединять множество пакетных систем (что, кстати, вполне логично, так как логика одинаковая). Да и лоничнее это - запилить одну логику для всего в одной тулзе, а частности (поддержка конкретной пакетной системы) релализовать уже на дочерних элементах наследующих логику (ООП-стайл же, ну).
debdiff - Debian.. но ведь, есть жизнь и на других планетах! к тому же, я часто сталкивался с тем что проги разработанные поклонниками Debian'а зачастую ооочень "дебианизированы", т.е. свои пути, зачастую привязка к чисто дебиановским пакетам и пр.. портирование таких вещей сильно затруднено.. проще написать своё чем выпускать патч для своего дистра..
> debdiff - Debian.. но ведь, есть жизнь и на других планетах!Думаю, что и для rpm есть аналогичное. А вот смысла в утилите, поддерживающей (криво) оба формата - нету никакого.
> тому же, я часто сталкивался с тем что проги разработанные поклонниками
> Debian'а зачастую ооочень "дебианизированы", т.е. свои пути, зачастую привязка к чисто
> дебиановским пакетамНе врите, пожалуйста. Дебиан достаточно жестко следует FHS. Что касается "чисто дебиановских" пакетов - таких в природе нет, исключая разве что специфичные для дебиановской разработки утилиты.
поглядите в зависимости Fatrat из Git.. для того чтобы собрать полнофункциональную версию надо портировать кусок из пакета, которого нигде кроме Debian'а нет! это только то с чем я непосредственно сталкивался.. так же могу привести пример по портированию на Mandriva/ROSA и OpenSUSE пакетов tclmore и ztcl необходимух для включения функции сжатия трафика в клиенте Tkabber(у них косяки с путями)
> поглядите в зависимости Fatrat из Git.Гляжу. Build-Depends: debhelper (>= 7.4.10), cmake (>= 2.6.0), libtorrent-rasterbar-dev (>= 0.14.6), libboost-system-dev, libboost-filesystem-dev, libboost-date-time-dev, libqt4-dev (>= 4.4.0), libqtwebkit-dev, qt4-dev-tools (>= 4.4.0), libgloox-dev (>= 0.9), libcurl4-gnutls-dev | libcurl-devdebhelper (>= 7.3.7), cmake (>= 2.6.0), fatrat-dev (>= 1.1.3). В debian/rules обычные пляски с ./configure && cmake. Чего вам там не хватило-то, болезный? :)
Я уж молчу, что к дебиану данный проект не имеет никакого отношения. Хотите стянуть наработки из дебиан (что вполне нормально) - это одно (идем сюда: http://anonscm.debian.org/gitweb/?p=collab-maint/fatrat.git). А если хотите работать с upstream непосредственно - идем в другое место (http://git.dolezel.info/?p=fatrat.git;a=tree) и не плачемся про плохой дебиан, а делаем работу самостоятельно.
плохо глядели...
цитата из файла INSTALL:
"Web interface | WITH_WEBINTERFACE | libpion-net"
найдите pion-net в других(не deb-base) дистрах..
То, что в других дистрибутивах этот софт не запаковали - личные половые трудности этих дистрибутивов. Проект http://www.pion.org/projects/pion-network-library никак с Debian не связан.Извините, но пока просто скопипастить работу с packages.qa.d.o - не получится. Мы над этим работаем. А вам, напоминаю, никто не мешает работать с upstream непосредственно и не пользоваться чужим трудом.
а у вас Fatrat собран к тому же еще и без поддержки java-плагинов судя по списку...
цитата из того же INSTALL:
"Java extensions | WITH_JPLUGINS | JRE 1.6, (JDK for compilation) "
читай внимательно!
берем два бинарных пакета, а на выходе получаем различия в исходном коде
там происходит обратная трансляция и компиляция, жаль выводить умеет только разницу,а не весь код, думаю тут дело в лицензионных ограничениях и масонских заговорах.
только что попробовал "pkgdiff dx3d9.cab dx3d11.cab" и слил патчи для вайна на 11 директ икс.
а если выпонить pkgdiff dx3d11.cab /dev/random то... (тсс это секрет)
> читай внимательно!
> берем два бинарных пакета, а на выходе получаем различия в исходном кодеГлупостей не пишите. Картинки, которые в тексте вам показали - различия между двумя src.rpm в одном примере и двумя тарболами в другом.
Для дебиан он умеет сравнивать бинарные пакеты (*.deb). Примерно также как и debdiff.
> там происходит обратная трансляция и компиляция
Ага, вызываемая телепатическим модулем.
бро, все действительно так как ты сказал?
> там происходит обратная трансляция и компиляция,нет.. он тупо сравнивает.. проверял на пакетах vacuum-im(которые сам же и собирал)..
выводится только отличия в заголовках и ина о том что сами бинарники различны..
странно, но pkgdiff windows7.iso /dev/random возвращает 0
>читай внимательно!
>берем два бинарных пакета, а на выходе получаем различия в исходном кодетам происходит обратная трансляция и компиляция, жаль выводить умеет только разницу,а не весь код, думаю тут дело в лицензионных ограничениях и масонских заговорах.
только что попробовал "pkgdiff dx3d9.cab dx3d11.cab" и слил патчи для вайна на 11 директ икс.
а если выпонить pkgdiff dx3d11.cab /dev/random то... (тсс это секрет)
>читай внимательно!
>берем два бинарных пакета, а на выходе получаем различия в исходном кодетам происходит обратная трансляция и компиляция, жаль выводить умеет только разницу,а не весь код, думаю тут дело в лицензионных ограничениях и масонских заговорах.
только что попробовал "pkgdiff dx3d9.cab dx3d11.cab" и слил патчи для вайна на 11 директ икс.
>а если выпонить pkgdiff dx3d11.cab /dev/random то... (тсс это секрет)Ваганыч, ты?
Я, в отличии от вас почитал еще и файл pkgdiff.pl который прилетел по git clone git://github.com/pkgdiff/pkgdiffТам 2327 строк средней компактности простого перлового кода. Для тебя лично могу разложить всю логику, провести анализ кода с разных позиции и проделать аналитическую работу с научной позиции (это когда не размахивают повсюду своим субъективным отростком (я ваш дом труба шатал) - а ищут пути достижения объективного результата). Только один момент: необходима компенсация моего времени. Все остальное - обсуждаемо.
>> Допустим, пробежаться по контенту source файлов диффом оптом мы можем сами
> Для этого не обязательно бегать самим - достаточно заставить побегать готовые утилиты
> (debdiff, думаю для rpm-ок тоже что-то найдется).
>> Дополнительно проводится анализ изменений с учетом типа файла, например, для библиотек оценивается изменение ABI
> На этом "например" и заканчивается все оригинальное. И только ради этого
> стоило городить трехколесный велосипед, вместо развития существующих утилит?Пожалуй, главной причиной независимого инструмента была цель абстрагироваться от формата сравниваемых пакетов. Debdiff работает только с Deb-пакетами, Urpmdiff - только с RPM-пакетами. Развитие Debdiff в плане добавления в него поддержки RPM выглядит, мягко говоря, странно. Также это было бы слишком сложно - весь код завязан на одном формате. Кроме того развивать там практически нечего - всего 1000 строк в одном инструменте и 200 в другом - легче сделать с нуля и возможно с дополнительной поддержкой опций этих двух инструментов.
Дополнительно к функциональности Debdiff и Urpmdiff (сравнение зависимостей, списка добавленных/удаленных файлов) PkgDiff классифицирует файлы, по-возможности сравнивает их содержимое, строит удобные HTML-отчеты и поддерживает сравнение не только RPM и Deb, но также и архивов (TAR.GZ, TAR.xz, и др.).
Также это всего лишь первая версия PkgDiff. В будущих версиях будет добавлена возможность оценки влияния изменений в пакете на зависимые пакеты в репозитории, а также детальные проверки для некоторых наиболее важных форматов файлов (например, для CLI - сравнение опций и тд.).
> Пожалуй, главной причиной независимого инструмента была цель абстрагироваться от формата сравниваемых пакетов.Но, простите, ЗАЧЕМ? Какой дистрибутив в здравом уме и трезвой памяти будет использовать ваши тридевять форматов одновременно?
> Развитие Debdiff в плане добавления в него поддержки RPM выглядит, мягко говоря, странно.
Да не поддержки RPM (хотя, заверните RPM в DEB через alien - будет вам и поддержка), речь шла о добавлении "оценки изменений ABI". Больше ровно ничего оригинального нет.
> Кроме того развивать там практически нечего - всего 1000 строк в одном инструменте и 200 в другом - легче сделать с нуля
Конечно, легче. Это не значит, что лучше.
>> Пожалуй, главной причиной независимого инструмента была цель абстрагироваться от формата сравниваемых пакетов.
> Но, простите, ЗАЧЕМ? Какой дистрибутив в здравом уме и трезвой памяти
> будет использовать ваши тридевять форматов одновременно?Например, в нашей сборочной системе (ABF) поддерживаются оба формата. Она используется как для сборки RPM-based дистрибутивов (например, ROSA), так и Deb-based (внутренние разработки для мобильных устройств). Кроме того, одновременное использование архивов (апстрим-пакетов) и бинарных пакетов - повсеместно.
>> Развитие Debdiff в плане добавления в него поддержки RPM выглядит, мягко говоря, странно.
> Да не поддержки RPM (хотя, заверните RPM в DEB через alien -
> будет вам и поддержка),При преобразовании с помощью alien теряются зависимости пакета. Так что такой способ не подойдет.
> речь шла о добавлении "оценки изменений ABI".
> Больше ровно ничего оригинального нет.Именно! Детальное сравнение содержимого файлов пакета - одна из основных фич, которых нет в других инструментах. Например, для библиотек - проверяются изменения в ABI (с помощью инструмента ABI Compliance Checker разрабатываемого в Лаборатории РОСА). Для текстовых файлов - отображается визуальный HTML отчет о различиях. Для man-страниц - производится интерпретация и уже затем текстовое построчное сравнение. И это только первая версия инструмента.
>> Кроме того развивать там практически нечего - всего 1000 строк в одном инструменте и 200 в другом - легче сделать с нуля
> Конечно, легче. Это не значит, что лучше.В общем случае - согласен, но конкретно в данном - все-таки лучше сделать новый инструмент. Разные цели - разные инструменты. Поддержка разных форматов и поддержка одного - это существенно разные цели.
> Например, в нашей сборочной системе (ABF) поддерживаются оба формата.Вот мне и любопытно, зачем? Ну, помимо галочек в аччотах и очередного дистроклепательства?
>> речь шла о добавлении "оценки изменений ABI".
>> Больше ровно ничего оригинального нет.
>
>Именно! Детальное сравнение содержимого файлов пакета - одна из основных фич, которых нет в других инструментах.Да есть, в том же debdiff (он умеет и dsc сравнивать, помимо прочего). Кроме, действительно, оценки изменений ABI. Интегрировали бы это в debdiff - вам бы спасибо сказали. Все требуемые зависимости там есть в пакетах.
>> Например, в нашей сборочной системе (ABF) поддерживаются оба формата.
> Вот мне и любопытно, зачем? Ну, помимо галочек в аччотах и
> очередного дистроклепательства?Сборочная система собирает пакеты разных форматов - как RPM, так и DEB. Зачем? Чтобы выпускать разные продукты на разных пакетных базах с помощью одной сборочной системы.
И никакого дистроклепательства нет. Международная Mandriva 2011 была выпущена, между прочим, в Лаборатории РОСА.
>>> речь шла о добавлении "оценки изменений ABI".
>>> Больше ровно ничего оригинального нет.
>>
>>Именно! Детальное сравнение содержимого файлов пакета - одна из основных фич, которых нет в других инструментах.
> Да есть, в том же debdiff (он умеет и dsc сравнивать, помимо
> прочего).Это всего лишь проверка одного файла, у нас же цель проверять все файлы.
> Кроме, действительно, оценки изменений ABI.
> Интегрировали бы это в debdiff - вам бы спасибо сказали. Все
> требуемые зависимости там есть в пакетах.После доработки Debdiff получился бы код следующего содержания - 90% нового кода и 10% старого из Debdiff. Причем код Debdiff будет сильно переработан, так как будет увеличен уровень абстракции от формата пакета. Так зачем же его использовать, если это только усложнит разработку и приведет к тому же результату?
> Сборочная система собирает пакеты разных форматов - как RPM, так и DEB. Зачем? Чтобы выпускать разные продукты на разных пакетных базах с помощью одной сборочной системы.Зачем? Я понимаю еще - разные версии из upstream. Но *это*... "Энтропия растет..." (ц)
Насколько я понимаю, оно ведь все-равно не умеет сравнивать пакеты в разных системах (foo-3.14.rpm vs foo-6.66.deb). Да и есть-ли смысл подобного сравнения вообще *на уровне пакетов*?
> Это всего лишь проверка одного файла, у нас же цель проверять все файлы.
"С данным инструментом я не знаком" - так было бы честно.
> Так зачем же его использовать, если это только усложнит разработку и приведет к тому же результату?
Затем, чтобы улучшить полезный инструмент для сообщества. Естественно, речь шла не о добавлении туда чужих форматов пакетов.
>> Сборочная система собирает пакеты разных форматов - как RPM, так и DEB. Зачем? Чтобы выпускать разные продукты на разных пакетных базах с помощью одной сборочной системы.
> Зачем? Я понимаю еще - разные версии из upstream. Но
> *это*... "Энтропия растет..." (ц)Объясняю на пальцах. Есть два дистрибутива. Один для Desktop'ов - Mandriva/ROSA (формат пакетов - RPM), другой для встроенных систем, основанный на Debian (формат пакетов - DEB). Оба разрабатываются в Лаборатории РОСА. А сборочная система одна на всех. Отсюда и необходимость в поддержке двух форматов. Не разрабатывать же две сборочные системы для каждого формата?!
> Насколько я понимаю, оно ведь все-равно не умеет сравнивать пакеты в разных
> системах (foo-3.14.rpm vs foo-6.66.deb). Да и есть-ли смысл подобного сравнения
> вообще *на уровне пакетов*?Сравниваются RPM'ы с RPM'ами и Deb'ы с Deb'ами соответственно.
>> Это всего лишь проверка одного файла, у нас же цель проверять все файлы.
> "С данным инструментом я не знаком" - так было бы честно.Я его запускал и прочитал код, а Вы? Приведите, пожалуйста, пример опции, с помощью которой можно сравнить содержимое всех файлов в пакете. Может я действительно что-то упустил?
>> Так зачем же его использовать, если это только усложнит разработку и приведет к тому же результату?
> Затем, чтобы улучшить полезный инструмент для сообщества. Естественно, речь шла не
> о добавлении туда чужих форматов пакетов.А может лучше сделать новый инструмент для сообщества, который дополнит или даже заменит старый?
> Не разрабатывать же две сборочные системы для каждого формата?!Можно не разрабатывать два дистрибутива :)
> Сравниваются RPM'ы с RPM'ами и Deb'ы с Deb'ами соответственно.
Вот и я о чем. Смысл такого действа вне конкретного дистрибутива - отсутствует напроч.
Для tgz с исходными текстами - тут совсем безнадежная замена diff. Наивная групировка измененных файлов по расширениям абсолютно бесполезна. Для статистики?
Почти любое изменение - затрагивает сразу множество файлов. Есть ведь нормальные репозитарии с исходными текстами, там все можно культурно сравнить. Связно, с историей правок между версиями. Почему не сделать по-человечески?
> Я его запускал и прочитал код, а Вы? Приведите, пожалуйста, пример опции, с помощью которой можно сравнить содержимое всех файлов в пакете. Может я действительно что-то упустил?
А я его еще и регулярно использую, в числе прочего. debdiff foo-v1.dsc foo-v2.dsc
> А может лучше сделать новый инструмент для сообщества, который дополнит или даже заменит старый?
Может. Но пока тут благие намерения - такой инструмент должен иметь возможность быть неинтерактивным, да и больше интегрироваться с конкретной пакетной системой.
Как бы то ни было, удачи.
я РОСист.. увидел сообщение о утилите в RSS от ROSALab.. скачал.. попробовал.. в общем полезно, НО несколько выбивается из "Mandriva/ROSA-way".. нет GUI!!!