Запущен в бета-режиме проект repology.org (http://repology.org/), направленный на сбор статистики об актуальности версий пакетов в репозиториях различных ОС и дистрибутивов Linux. В рамках проекта собирается информация о пакетах, представленных в портах FreeBSD и OpenBSD, pkgsrc, репозиториях Debian, Ubuntu, Gentoo, Arch Linux, OpenSUSE, ALTLinux Sisyphus, SlackBuilds, а также в Chocolatey (пакетный менеджер для Windows), и на основе сравнения номеров версий выявляются пакеты, требующие обновления.
Для сравнения используются только source-пакеты (так как бинарные пакеты во многих дистрибутивах разбиваются
на части, например libfoo, libfoo-dev, libfoo-doc, libfoo-dbg,
корректное сравнение которых не представляется возможным), а для
случаев когда пакеты для одного и того же ПО имеют в разных
дистрибутивах разные названия используется мощная система правил
преобразования названий к "общему знаменателю".
Проект предполагает широкий круг применений и может быть полезен
как мэнтейнерам пакетов (как ещё один способ определять пакеты,
требующие обновления, налаживать контакты с мэнтейнерами из других
дистрибутивов и унифицировать метаинформацию), так и авторам ПО
(видеть состояние пакетов для своего проекта во всех дистрибутивах и налаживать контакты с мэнтейнерами) и простым пользователям
(определять наличие и актуальность нужных пакетов в различных
дистрибутивах).
На сайте можно посмотреть общий список всех известных пакетов,
выборки по мэнтейнерам и репозиториям, список устаревших пакетов
для каждого репозитория, список пакетов-кандидатов на добавление
(пакет, отсутствующие в репозитории, но присутствующий в большинстве
других), а также сводную статистику.URL: http://repology.org/
Новость: http://www.opennet.ru/opennews/art.shtml?num=45505
Годнота! Думал что таких проектов не сущетсвует в природе.
конкретно для openbsd уже давно существует
http://distrowatch.com
http://distrowatch.com/packages.php? Там несколько десятков пакетов и те обновляются руками.
> http://distrowatch.com/packages.php? Там несколько десятков пакетовДа.
> и те обновляются руками.
Список/эвристики -- видимо, да, а версии -- явно автоматом.
Нет, их довольно много, но, к сожалению, они привязаны к одному дистрибутиву и у них гораздо меньшие покрытие и функциональность.http://portroach.openbsd.org/
http://portscout.freebsd.org/
http://monitor.nixos.org/
https://github.com/whohas/whohas
http://www.ki.nu/~makoto/pkgsrc/check-update/20160928-17/00_...
https://github.com/iksaif/euscanЗато они ищут новые версии в upstream, что repology пока не умеет. Но может либо научиться сама, либо аггрегировать данные от одного из этих сервисов.
> Зато они ищут новые версии в upstream, что repology пока не умеет. Но может либо научиться сама, либо аггрегировать данные от одного из этих сервисов.Дим, привет.
а если немножко от portscout взять? оно умеет же отслеживать более свежие версии (MASTER_SITES смотрит?)
Да, и даже довольно умно. Но там пока очень много false positives, которых я хотел бы избежать вовсе, по возможности. Пока мысль такая, что в upstream нужно смотреть самому, при том весьма осторожно.
> Зато они ищут новые версии в upstream, что repology пока не умеет.
> Но может либо научиться сама, либо аггрегировать данные от одного из
> этих сервисов.Лучше от нескольких, тогда получится чаще избегать ловушки "пакет переехал, смотрелки смотрят по прежнему адресу".
От нескольких - разве что чтобы отфильтровать FP. А что кто-то из них может ловить переезд пакета я сильно сомневаюсь. Как раз это ловит сам repology после того как это обнаружил кто-то из людей.
я пользуюсь https://pkgs.org
Прикольно, ребята постарались.
Посмотрел тут кто разрабатывает... Меня всегда поражали две вещи - почему у FreeBSD такие скиловые люди. И что такие скиловые люди находят в FreeBSD. КАК можно столько контрибьютить https://github.com/AMDmi3 в течении года??! Респект разработчику!
В любых свободных проектах хватает "скилованых" людей.А что не так в FreeBSD? Или вы против 4 свобод? ;)
> А что не так в FreeBSD?Всё "так", узбагойся. Просто конурирующая секта.
Дружба с аплаянс вендорами, как esr завещал отделу маркетинга - это Важно, мы в курсе.
"A BSD style license is a good choice for [...]" --https://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html
>Или вы против 4 свобод? ;)
Мы, в основном, против пятой "свободы" для пятой колонны -- она, вишь ты, перечёркивает все четыре предыдущие и работает не с и не для пользователей, а вместо и против них. Ещё раз: с проприертарщиками и против пользователей.
Это если Вы пропустили все предыдущие 30 лет "дискуссии" BSDL-vs-GPL. Где Вы пропадали?..
|
https://www.gnu.org/philosophy/why-copyleft.html
https://www.gnu.org/philosophy/pragmatic.html
---Впрочем, можете и нас не :( поздравить: http://lwn.net/Articles/706585/
+++http://www.opennet.ru/openforum/vsluhforumID3/107903.html#129 ;; http://www.opennet.ru/openforum/vsluhforumID3/109155.html#17
Ну вот, всё раньшем меня написал...
>Мы, в основном, против пятой "свободы" для пятой колонныВы за свободу в пределах своей клетки, всего лишь.
Вот тут http://www.opennet.ru/openforum/vsluhforumID3/109571.html пишется о том, что фонд СПО хочет иметь имущественные права на код, который получает. Чем вам не пятая колонна? Одна фирма получает права на код, и потом может по своему желанию менять лицензию. Почему их не устраивает собственная ГПЛ, и им нужны ещё и имущественные права?
Но рабам не положено задавать вопросы — им положено лишь поддерживать хозяина. Так что в ваши свободы для первых четырёх колонн не верят сами апологеты ГПЛ настолько, что не хотят получать код под своей лицензией, им нужны такие права на код, которые как раз и даёт лицензия БСД. А вот распространять то, что получили, они хотят под лицензией, которая обязывает _других_, а не их самих.
Но разве вы способны сами мыслить, чтобы понять как вас надули? Ведь пророк глаголет свосем иное...
>>Мы, в основном, против пятой "свободы" для пятой колонны
> Вы за свободу в пределах своей клетки
> фонд СПО хочет иметь имущественные права на код, который получает. Чем
> Но рабам не положено задавать вопросы — им положено лишь поддерживать хозяина.
> даёт лицензия БСД. А вот распространять то, что получили, они хотят
> Но разве вы способны сами мыслить, чтобы понять как вас надули? ВедьКонструктивненько, чо. Я вижу, ты прямо в нетерпении ждёшь ответа. Оскорбился, всплакнул? Ну, ничего-ничего, всё пройдёт.
> пророк глаголет свосем иное...
О, это хорошо известный чувак в сообществе OpenStreetMap, много вкусного и полезного сделал для проекта, правда уже год наверное, как куда-то пропал.
> Посмотрел тут кто разрабатывает... Меня всегда поражали две вещи - почему у
> FreeBSD такие скиловые люди.Накостылить скрипт на питоне много скилла не нужно.
> И что такие скиловые люди находят в FreeBSD
В первую очередь систему портов, которой, по моему скромному мнению, при всех её (постепенно решаемых, впрочем) недостатках, аналогов среди других репозиториев нет. Думаю именно из-за своих качеств, несмотря на, наверное, на порядок меньшую пользовательскую и разработческую базы она по количественным показателям не сильно отстаёт от лидера Debian и обгоняет другие дистрибутивы. А со стороны операционной системы - здоровый консерватизм и целостность экосистемы при отсутствии каких-то значительных недостатков.
Сравнил ж... с пальцем - целостную стабилизированную систему с минным полем роллинга.
Только надо учитывать, что это сравнение одного минного поля с другим. Они ж всё берут по последней версии пакета независимо от стабильности (понятно, что стабильность хрен сравнишь). В результате будет, что в одном дистрибутиве версия 1.1 стабильная, в другом - она же падучая, в третьем - есть 1.2, которую никто больше добавлять не стал, так как известно, что она крива и ломает пол-системы, в четвёртом - версия, которой вообще в природе нет (вроде Seamonkey 2.42).В общем, пользователям на это надо смотреть с крайней осторожностью, понимая, что нюансов масса. Разработчикам и маинтайнерам, правда, толку больше - если не выльется в пузомерку.
> Разработчикам и маинтайнерам, правда, толку больше - если не выльется в пузомерку.Выльется, вестимо. Можно, конечно, надеяться, что поправят версионирование. Если, конечно, им кто-нибудь напишет, что с ним проблемы, хотя наверняка уже давно заметили и решили, что "нам так жить не мешает".
А пользователи... Пользователям на это смотреть вредно, ибо сервис в некотором роде укрепляет совершенно необоснованную веру в то, что последние версии программ - самые лучшие.
> А пользователи... Пользователям на это смотреть вредно, ибо сервис в некотором роде
> укрепляет совершенно необоснованную веру в то, что последние версии программ -
> самые лучшие.Я бы тут поспорил. Отсиживаться на старье куда более спорная стратегия.
>> А пользователи... Пользователям на это смотреть вредно, ибо сервис в некотором роде
>> укрепляет совершенно необоснованную веру в то, что последние версии программ -
>> самые лучшие.
> Я бы тут поспорил. Отсиживаться на старье куда более спорная стратегия.Сложный вопрос -- вспомнился wu-ftpd между 2.42 и 2.6, например.
Версиомания достаточно распространена, заразна и вредна, чтоб был смысл накатать краткую вводную статью для пользователей и предложить автору сайта её взять.
> Сложный вопрос -- вспомнился wu-ftpd между 2.42 и 2.6, например.А что с ним было? Мне правда интересен живой пример.
>> Сложный вопрос -- вспомнился wu-ftpd между 2.42 и 2.6, например.
> А что с ним было? Мне правда интересен живой пример.Насколько мне известно, сервер этот прославился тем, что в нём впервые была выявлена и эксплуатирована уязвимость дефекта форматных строк.
Как это связано с обновлением до 2.6?
> Как это связано с обновлением до 2.6?CVE–2000–0573
Цитата из бюллетеня CVE: «Функция lreply в FTP–сервере wu–ftpd версии 2.6.0 и более ранних плохо контролирует форматную строку из не заслуживающего доверия источника, что позволяет противнику выполнить произвольный код с помощью команды SITE ЕХЕС». Это первый опубликованный эксплойт, направленный против ошибки в форматной строке. Заголовок сообщения в BugTraq подчеркивает серьезность проблемы: «Удаленное получение полномочий root по крайней мере с 1994 года».
> Цитата из бюллетеня CVE: «Функция lreply в FTP–сервере wu–ftpd версии
> 2.6.0 и более раннихТ.е. никакой регрессии при обновлении не было.
Так, я понял. Мы балбесы. Я было подумал, что этот дефект возник после 2.4.2, а в 2.6 был обнаружен и пофикшен наконец. Но похоже, что мы упустили главное.Миша ведь написал:
> Сложный вопрос -- вспомнился wu-ftpd между 2.42 и 2.6, например.Видимо, суть именно в 2.42, которое на самом деле должно было быть 2.4.2.
В любом случае, тут надо бы с Михаила подробности вытрясти. А то какие там могут быть проблемы - не понятно. Именно для таких случаев эпоху и придумали.
> Миша ведь написал:
>> Сложный вопрос -- вспомнился wu-ftpd между 2.42 и 2.6, например.
> Видимо, суть именно в 2.42, которое на самом деле должно было быть 2.4.2.Да, это "очепятка" в памяти (ещё смотрел на эти циферки, смотрел, но не вспомнил сразу). Речь про 2.4.2 и 2.6.0+.
> А то какие там могут быть проблемы - не понятно.
Смена команды разработчиков -- новые продолжили проект, добавили желанную функциональность и вагон технологических отверстий. А люди грамотные совершенно не поспешали перебираться на новую версию ещё до того, как последствия смены команды стали выявляться уже фактами.
> Только надо учитывать, что это сравнение одного минного поля с другим. Они
> ж всё берут по последней версии пакета независимо от стабильности (понятно,
> что стабильность хрен сравнишь). В результате будет, что в одном дистрибутиве
> версия 1.1 стабильная, в другом - она же падучая, в третьем
> - есть 1.2, которую никто больше добавлять не стал, так как
> известно, что она крива и ломает пол-системыВо-первых, это единичные случаи. Во-вторых, если новая версия работает в одном дистрибутиве, значит могла бы работать и везде. По меньшей мере о ней всегда нужно знать, по большей - менять что-то либо в самом пакете, либо в дистрибутиве, чтобы она нормально работала.
> в четвёртом - версия, которой вообще в природе нет (вроде Seamonkey 2.42).
А для этого есть игнорирование версий через правила.
Таких "единичных случаев" будут набираться десятки процентов. Это, в конце кончов, только те ситуации, что мне в течение 30 секунд в голову пришли. Наверняка есть гораздо больше вариантов.И нет, если работает в одном дистрибутиве - не факт, что будет работать в других. Начиная с того, что там вообще BSD с линуксом перемешали, и заканчивая тем, что сама инфраструктура может не позволять. Например, в одном пакеты собираются одной версией компилятора, с которой всё ок, а в другом - перебрались на новую, в которой некоторые пакеты ломаются, и нужно ждать, пока авторы выкатят новые версии с фиксами.
А любые рукописные "правила" на десятках тысяч пакетов просто обречены на катастрофическую неполноту.
> И нет, если работает в одном дистрибутиве - не факт, что будет работать в других. Начиная с того, что там вообще BSD с линуксом перемешалиЯ больше скажу, там и Windows (Chocolatey) есть. Только что с того? От того под какую систему собран софт, версия не меняется. А Linux-специфичный софт, например, под другие системы будет просто отсутствовать, при этом среди Linux'ов корректно сравниваться.
> и заканчивая тем, что сама инфраструктура может не позволять. Например, в одном пакеты собираются одной версией компилятора, с которой всё ок, а в другом - перебрались на новую, в которой некоторые пакеты ломаются, и нужно ждать, пока авторы выкатят новые версии с фиксами.
Так и в этом случае всё корректно, локальные проблемы дистрибутива - не повод не обновлять пакет. Мантейнер должен помнить что пакет нужно обновить, пользователь должен видить что пакет устарел. А ждать не нужно, нужно коммитить в апстрим. Я надеюсь repology будет мотивировать также и к этому.
> А любые рукописные "правила" на десятках тысяч пакетов просто обречены на катастрофическую неполноту.
Правила нужны только для исключений, а их будет от силы несколько сотен. За час я добавил их до буквы g (правда, тогда поддерживалось меньше репозиториев, так что надо начать с начала), т.е. за один день вполне можно причесать весь список. На самом деле, проект не сильно пострадает если отдать правила индивидуальных пакетов на откуп тому кому они интересны (т.е. мантейнерам и авторам) - для них проект прежде всего делался, в их руках сделать его для себя удобнее, а на статистику, которая прежде всего интересна обычным пользователям, это не влияет.
Поиска по пакетам нет - Минус
Репо Debian Unstable - Зачем мне смотреть что там в нестабильном репо, если все ставят пакеты из стабильного? Бред.
> Поиска по пакетам нет - МинусЭто пока прототип, статический сайт без бэкенда. В будущем с БД бэкендом будет и поиск, и более гибкая фильтрация и много чего ещё.
> Репо Debian Unstable - Зачем мне смотреть что там в нестабильном репо, если все ставят пакеты из стабильного?
Основная аудитория проекта - мантейнеры, а цель - находить последние версии. Из stable ни свежих версий не наковырять, ни обновлять его до них никто не будет. Но вообще поддержка stable и testing есть, просто они не показываются в таблице (на самом деле в неё банально по ширине всё не влезает). В будущем будут видны и они.
Backports???
> Backports???Можно добавить, но ничего кардинально не изменится.
>> Backports???
> Можно добавить, но ничего кардинально не изменится.Вот так выглядят отдельно дебиановские репы (осторожно, большой html может повесить браузер): http://test.repology.org/debian.html. В stable не на что смотреть кроме устаревших и отсутствующих пакетов.
Ни о чём. На Aalib посмотрите: он не менялся уже сто лет, во всех репах одна и та же версия. Но pkgsrc решил что 1.4rc5 можно назвать 1.4.0.5, поэтому табличка считает, что у него самая свежая версия.
ай-ай-ай, какой плохой автор - не смог сделать нормальный анализатор или прописать руками для всех тысяч пакетов нормальный правила!!!! всё, закапывайте!!! и ни в коем случае не пишите автору - пусть сам обо всём догадывается, раз такой умный, что сам что-то делает!
Хм. Вообще, я тут подумал как следует. Вы правы. Этот сервис позволит в некотором роде выявлять ошибки версионирования в различных дистрибутивах. Правда, берёт сомнение, что это кого-нибудь волнует. Но, как говорится, вдруг?Но вообще говоря, смысла в этой табличке не много. Ну посмотрели, оценили. Погудели каждый за свой дистрибутив. И всё.
> Хм. Вообще, я тут подумал как следует. Вы правы. Этот сервис позволит
> в некотором роде выявлять ошибки версионирования в различных дистрибутивах. Правда, берёт
> сомнение, что это кого-нибудь волнует. Но, как говорится, вдруг?Это не основная и даже не значичельная цель проекта, но если кто-то где-то исправит фейковую версию, я буду рад. Во FreeBSD я несколько уже исправил, к слову.
> Но вообще говоря, смысла в этой табличке не много. Ну посмотрели, оценили.
> Погудели каждый за свой дистрибутив. И всё.Пользователи - да. А вот для мантейнеров это способ узнать о новых версиях софта, пакеты которого они поддерживают и, соответственно, своевременно обновить свои пакеты. Главная цель - в этом. Авторам также полезно будет узнать где, как и кем их проекты опакечены.
> Пользователи - да. А вот для мантейнеров это способ узнать о новых
> версиях софта, пакеты которого они поддерживают и, соответственно, своевременно обновить
> свои пакеты.Мейнтейнер и без того подписан на рассылку разработчиков своего пакета. Это и оперативнее, и полезнее.
> Авторам также полезно будет узнать где, как и кем их проекты опакечены.
А зачем? Ну узнают, а что с этим делать-то? Если какую багу выявили, так это не разрабы в пакет лезут, а мейнтейнеры эскалируют багу, и посылают в апстрим патчи.
> Мейнтейнер и без того подписан на рассылку разработчиков своего пакета.
> Это и оперативнее, и полезнее.Это хороший...
>> Мейнтейнер и без того подписан на рассылку разработчиков своего пакета.
>> Это и оперативнее, и полезнее.
> Это хороший...А так это сервис для плохих ментейнеров? Что ж вы сразу ;-) молчали-то!..
> Мейнтейнер и без того подписан на рассылку разработчиков своего пакета. Это и оперативнее, и полезнее.С разморозкой, рассылки давно канули в Лету. А когда существовали, средством оповещения о новых версиях ни коим образом не были, потому что были помойками. Оповещение о новых версиях - это когда только о новых версиях, и сразу всех пакетов. И да, это repology или сканнеры апстрима упомянутые выше. Индивидуальные проекты ни на что такое не способны и никогда не будут.
> А зачем? Ну узнают, а что с этим делать-то? Если какую багу выявили, так это не разрабы в пакет лезут, а мейнтейнеры эскалируют багу, и посылают в апстрим патчи
Увы, далеко не все, не всё и не всегда. Авторы должны видеть общую картину, мантейнеры должны видеть общую картину и как опакечивают те же пакеты в соседних дистрах, и все должны взаимодействовать со всеми. И push, и pull, и авторы лезут, и мантейнеры "эскалируют". Просто единой точки взаимодействия до сих пор не было, а теперь у неё есть шанс появиться.
> С разморозкой, рассылки давно канули в Лету.Дальше не читал. :)
Заходите как-нибудь к нам, в реальный мир. Тут интересно.
Вот возьми первую страницу с repology и выпиши сюда мейллисты всех проектов оттуда. Посчитаем вместе и посмеёмся кто в реальном мире а кто загнался.
> Вот возьми первую страницу с repology и выпиши сюда мейллисты всех проектов
> оттуда. Посчитаем вместе и посмеёмся кто в реальном мире а кто
> загнался.А чего это именно Я должен тратить время? А давайте-ка Вы сами его потратите, чтобы доказать *свои* слова.
Как говорится, на одного дурака...
Действительно, что это вы должны доказывать своё же утверждение.Не мешки ворочать, что вам что Мише.
> С разморозкой, рассылки давно канули в Лету.Нет, конечно. С проблемами gmane не путаете часом?
> А когда существовали, средством оповещения о новых версиях ни коим образом не были
Ознакомьтесь с архивами *-announce@ используемых проектов, что ли.
> Индивидуальные проекты ни на что такое не способны и никогда не будут.
"Категорические утверждения абсолютно неверны!" (ц)
Вам то же предложение. Первая страница, все мейллисты в студию. Скооперируйтесь с фантазёром выше, проще позориться будет.
> Вам то же предложение.Я и так в курсе, что Ваше утверждение в #77 ложно (точнее, ложны минимум два из сделанных там) -- поскольку этими самыми анонсовыми рассылками пользуюсь в обе стороны.
И нет, Вы ляпнули чушь -- Вы и гробьте время на её доказательство. Ну или учитесь обобщать поосторожней. Пожелание такое.
Спасибо, что и следовало доказать.
И не сможет. Именно поэтому опираться на эту штуку для всех, кроме тех, кто в курсе специфики конкретного пакета - рискованно.
> Ни о чём. На Aalib посмотрите: он не менялся уже сто лет,
> во всех репах одна и та же версия. Но pkgsrc решил
> что 1.4rc5 можно назвать 1.4.0.5, поэтому табличка считает, что у него
> самая свежая версия.Пусть это будет уроком для тех кто не использует semver, а также использует alpha/beta/rc и другие приписки (которые semver, увы, разрешает). Хотя тут, конечно, виноват мантейнер pkgsrc, проставивший несуществующую версию. Её можно заигнорировать, что я и сделаю.
Пусть это будет урокм для тех, кто не в курсе, что пытаться заставить десятки и сотни тысяч не связанных друг с другом людей ходить строем обречены на неудачу.Ну и заодно - чудесный пример маразма, когда в пакетную базу пихают rc.
> Пусть это будет урокм для тех, кто не в курсе, что пытаться
> заставить десятки и сотни тысяч не связанных друг с другом людей
> ходить строем обречены на неудачу.Ой ли, что ж вы по http постите как и все, а не на своём собственном единственно правильном протоколе? Десятки и сотни тысяч используют semver, интуитивно, даже не зная о нём. А отдельные яркие индивидуальности... Не, никто не заставляет, но используете кривые версии - терпите что в вас все будут тыкать пальцем. Я бы предложил для таких проектов большую позорную надпись показывать.
> Ну и заодно - чудесный пример маразма, когда в пакетную базу пихают
> rc.Не, это пример маразма которым являются приписки типа rc, потому что по сути он релиз. И в дистрибутивы пакеты добавляют смотря на содержание, а не буковки в версии. Есть и беты и альфы, и проблема не в том что они в дистрибутивах, а в том что они названы бетами и альфами.
> Ни о чём. На Aalib посмотрите: он не менялся уже сто лет,
> во всех репах одна и та же версия. Но pkgsrc решил
> что 1.4rc5 можно назвать 1.4.0.5, поэтому табличка считает, что у него
> самая свежая версия.А это ловите Чеусова или ещё кого из netbsd'шников и передавайте авторам тумаков за такие диверсии ("в плюс", когда семантически -- "в минус" от 1.4, те же тильда-версии не от хорошей жизни в демьяне или где там придумали).
>мощная система правил преобразования названий к "общему знаменателю"Или, по-простому, костыли
>>мощная система правил преобразования названий к "общему знаменателю"
> Или, по-простому, костылиЕстественно. А по-другому никак, потому что один и тот же пакет и даже одну и ту же версию могут называть кучей разных способов. Я надеюсь проект поможет это исправить, для себя я даже знаю какие порты можно переименовать во FreeBSD, но и с простынёй правил можно неплохо жить.
>Естественно. А по-другому никак, потому что один и тот же пакет и даже одну и ту же версию могут называть кучей разных способов.По-другому еще как. Развертываете на своих серверах в Яндексе 100500 всех возможных дистрибутивов и версий, а далее на основе их систем, их внутренних репозиториях выделяете пакеты и привязываете по основным урлам к собственно архивам программ, кои обычно лежат либо на авторских серверах, либо в конкретных репах, по конкретным адресам, с конкретными... Вобщем, все можно сопоставить и с точностью до миллиметра.
Просто вам столько не платят =)
Развёртывать дистрибутивы для этого совершенно не нужно, но идея сравнивать по upstream url отличная, добавил себе issue. 100% результатов это, правда, всё равно не даст, к тому же не везде url просто выпарсить.
Для 100% сопоставления нужен только адрес архива, который используется в сборке. Тогда будет 100%. Как парсить или не парсить эти адреса это дело десятое, ясно, что выполнить задачу возможно. Успехов.
> Для 100% сопоставления нужен только адрес архива, который используется в сборкеВ сборках и сводных данных репозитория его нет почти никогда, потому что после сборки он уже никому не нужен. А полноценно парсить исходники (ebuild, pkgbuild, slackbuild, .spec, порты) - нетривиальная задача.
> Тогда будет 100%
Не будет, будет только возможность сказать что некоторые пакеты имеют одну версию, даже при том что она записана по-разному. В некоторых случаях это улучшит сравнение, в других не даст ничего.
Жалко мне не платят за идеи =) Чтобы я сделал на мощностях Яндекса?
1. Парсим ebuild, pkgbuild, slackbuild, .spec, порты
2. Извлекаем имя проекта/пакета
3. Извлекаем адреса файлов с архивом
4. Выкачиваем архив к себе + запоминаем откуда выкачали его
5. Для сопоставления пакета в одном дистрибутиве с другим пакетом с тем же именем, для выяснения (уместней сказать уточнения) версии в случае спорной ситуации, когда используется зеркало (другой URL) выкачиваем второй архив и далее по чексам выясняем % схождения.
6. Если имя, версия одинаковы, но есть расхождение в архивах, то тут нужна доп. логика, которую придется додумывать вам. Таких ситуаций, именно расхождения сумм должно быть менее 5%, если не около 1-2%.
7. Данные по расхождениям могут использоваться для аналитики, с последующими публикациями по найденным "артефактам". Вполне можно найти что-то стоящее.Все это нереально выводит проект на след. уровень, где методология с архивами лишь дополняет вашу логику на приличный процент "попаданий", а при соответсвующих доработках может довести и до 100%. Вопрос в том, что для вас является 100% попаданием. Пока что я слышу речь о названиях и версиях. Я же предлагаю большее... и сложнее в реализации. С соответсвующим выхлопом на выходе =)
Смотрите сами надо вам это или не надо.
> Жалко мне не платят за идеи =) Чтобы я сделал на мощностях Яндекса?Мощности Яндекса тут никому не нужны, всё можно сделать на VPS 10G/1G/1core.
По остальному мне нечего добавить к написанному выше - парсить адреса файлов нетривиально, да, это поможет в некоторых случаях, но никакого "следующего уровня" не будет. Зачем вы что-то собрались качать я вообще не понял.
А, так ты из тех персонажей, кто занимается это сомнительной идеей? Хм, ну тогда хотя бы понятно, чего ты её защищаешь.
> Развёртывать дистрибутивы для этого совершенно не нужно, но идея сравнивать по upstream
> url отличная, добавил себе issue. 100% результатов это, правда, всё равно
> не даст, к тому же не везде url просто выпарсить.Можно пытаться делать нечёткое сравнение по спискам файлов, но это если забирать те исходники, а не только метаданные... ну и тоже случаев fp не оберёшься.
Просто оставлю это здесь
http://pkgs.org
> Просто оставлю это здесь
> http://pkgs.orgЭто всего лишь поиск по пакетам, причём по бинарным, на небольшом наборе дистрибутивов.
> Просто оставлю это здесь http://pkgs.orgАвтор давно в курсе :-)
PS: и да, это разные проекты.
Очень полезный проект, пусть и сырой пока. Успехов авторам.
версию пакета можно нарисовать любую и соответственно подделать, тут надо что-то в виде цифровой подписи пакета ...
> версию пакета можно нарисовать любую и соответственно подделать, тут надо что-то
> в виде цифровой подписи пакета ...Исходников? В которых скрипты сборки и индивидуальные патчи для конкретных дистрибутивов :)
подписанные коммиты
> версию пакета можно нарисовать любую и соответственно подделатьЧтобы что, статистику испортить?
ну например подделать версию ssh на дырявую или пакет с ключами, выдавая за новую версию
> подделать версию ssh на дырявую или пакет с ключами, выдавая за новую версиюАга, предварительно подсунув подделку в апстрим и/или репозитории всех отслеживаемых систем/дистрибутивов. Задача-то тривиальная, любой школьник справится.
>> подделать версию ssh на дырявую или пакет с ключами, выдавая за новую версию
> Ага, предварительно подсунув подделку в апстрим и/или репозитории всех отслеживаемых систем/дистрибутивов.
> Задача-то тривиальная, любой школьник справится.зачем во все - и одной хватит: в отдельно взятом дистре просто подменить версию и выдать за нормальную, либо под видом обновлений
Fedora то почему нет?
> Fedora то почему нет?Я пока не нашёл где можно достать сводную информацию о её пакетах. Есть полурабочий вариант парсящий список пакетов из https://admin.fedoraproject.org/pkgdb/api/, но в этом API нет версий. Поэтому потом приходится качать и парсить отдельные спеки с http://pkgs.fedoraproject.org/cgit/rpms/. Это очень медленно и ненадёжно. Если есть лучшие идеи - с удовольстаием выслушаю.
>> Fedora то почему нет?
> Если есть лучшие идеи - с удовольстаием выслушаю.Судя опять же по https://watch.altlinux.org/pub/watch/watch-by-name.txt -- у viy@altlinux какие-то работающие идеи по поводу федоры есть и уже реализованы для фреймворка DistroMap.
Получаем любое зеркало:
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-25&...
где fedora-25 - версия, x86_64 - архитектура.в repodata/repomd.xml находим линк на data type="primary" (если больше нравится xml) или data type="primary_db" (если нравится sqlite)
скачиваем файл ( напр. repodata/f7e3ab389aeb31e6bf4651638aa0c6c2d7e70f868faa118fdde2f03fcad23175-primary.xml.gz) и там будут и названия и версии
...
<package type="rpm">
<name>0ad</name>
<arch>x86_64</arch>
<version epoch="0" ver="0.0.20" rel="4.fc25"/>
...
<package type="rpm">
<name>0ad-data</name>
<arch>noarch</arch>
<version epoch="0" ver="0.0.20" rel="1.fc25"/>
Хм, sounds like a plan. Так сейчас точно так парсится opensuse. Пропустил я этот момент с федорой. Спасибо.
Спасибо, поддержка Федоры добавлена.
Нету поиска по названию пакета. Сириусли?
Да, пока нет.
уиии! gentoo-sources есть только под gentoo! ^_^
ребятам бы накатать какое-нибудь сведение эквивалентных пакетов
Нужно добавить поиск и репозитории Rosa, NixOS и GuixSD.
> Нужно добавить поиск и репозитории Rosa, NixOS и GuixSD.Будет здорово если подскажете где брать информацию по этим пакетам.