The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Представлена бета-версия Cupt - проекта, продолжающего развитие APT

25.09.2009 15:27

Евгений Любимкин, ранее участвовавший в разработке APT, представил в списке рассылки разработчиков Debian GNU/Linux бета версию первого релиза написанной на языке Perl системы управления пакетами Cupt 1.0, продолжающей развитие APT. Работа над Cupt была начата зимой 2008 года с целью создания переработанного варианта APT, устраняющего проблемы, связанные с архитектурой и реализацией. В настоящее время cupt интегрирован в "unstable" ветку Debian. Проект еще далек до использования в качестве полной замены APT, но может использоваться совместно с такими утилитами как apt-get, apt-cache и aptitude, так как он базируется на стандартных для APT индексах, кэшах и файлах конфигурации.

Реализованные в Cupt возможности:

  • Полнофункциональная строгая система разрешения проблем с зависимостями;
  • APT-подобная утилита для работы из командной строки;
  • Возможность регистро-независимого поиска;
  • Использование пакетов из разных веток с сопоставлением по имени source-пакета или по заданной через строковую маску группе пакетов;
  • Настраиваемые подкоманды 'depends' и 'rdepends'. Поддержка подкоманд "satisfy" и 'shell';
  • Поддержка сжатых методом LZMA индексов;
  • Поддержка подключения внешнего модуля для решения проблем с зависимостями;
  • Возможность синхронизации версий исходных текстов;
  • Интеграция возможностей утилиты debdelta.

Не реализованы:

  • Работа с источниками cdrom://;
  • Поддержка PDiff-ов.


  1. Главная ссылка к новости (http://lists.debian.org/debian...)
  2. OpenNews: Представлен проект по созданию пакетного менеджера APT2
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/23577-apt
Ключевые слова: apt, Cupt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, kost BebiX (?), 16:25, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Перл???
     
     
  • 2.6, PereresusNeVlezaetBuggy (ok), 16:59, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Он самый. Что замечательно (от слова "замечать"), в OpenBSD поступили в своё время аналогично: унаследованные от фряшной системы портов утилиты pkg_* были переписаны (и впоследствии значительно доработаны) на Perl. На скорость никто не жалуется. Perl,  кстати, вообще довольно быстрый, когда дело касается ввода-вывода: у меня получалось терять не более 25% производительности на задачах типа "скопировать вон ту кучу файлов, сжимая по дороге через gzip".
     
     
  • 3.10, Warhead Wardick (?), 18:11, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • –2 +/

    for infile in *.pl; do gzip -9 -c $infile > /path_to_pomoika/$infile.gz; done

    А уж при чём "скорость" перла в такой задаче ... он ну очень быстро передаёт имя файла в cp, gzip и иже с ними? Угадал? А кто медленно? В общем - смотри пп 1.

     
     
  • 4.11, PereresusNeVlezaetBuggy (ok), 18:23, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/

    >
    >for infile in *.pl; do gzip -9 -c $infile > /path_to_pomoika/$infile.gz; done
    >
    >А уж при чём "скорость" перла в такой задаче ... он ну
    >очень быстро передаёт имя файла в cp, gzip и иже с
    >ними? Угадал? А кто медленно? В общем - смотри пп 1.

    Не-не-не. Речь в моём случае о том, что Perl через pipe передаёт данные gzip'у, оттуда они попадают в SSH и далее в сеть. То есть цепочка:

    диск => perl => gzip => ssh => сеть => ssh => perl => диск

    Производительность мерялась на учатке "диск => perl => gzip" по сравнению с аналогичной реализацией на C (смею уверить, не безграмотнее версии на Perl).

     
     
  • 5.12, Аноним (-), 18:36, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    При наличии смекалки это решается через pipe и ssh -c

    Другой вопрос, что если нужно реально независимое от платформы решения (даже для оффтопика), то тогда perl надежда и опора администратора.

     
     
  • 6.13, PereresusNeVlezaetBuggy (ok), 18:40, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >При наличии смекалки это решается через pipe и ssh -c

    А я и не говорил, что задача была только в передаче файлов. :) Там бизнес-логики тоже хватает. По сути, задача была в написании бэкапной системы. Решения рассматривались разные, от bacula до собственной реализации на C. По различным причинам, в которые вдаваться долго, лень и нет смысла, было выбрано написание своей системы на Perl.

    >Другой вопрос, что если нужно реально независимое от платформы решения (даже для
    >оффтопика), то тогда perl надежда и опора администратора.

    И это тоже верно.

     
  • 2.9, stranger (??), 17:38, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то тестовые варианты rpm тоже были сначала на перле написаны. И уже потом, после отработки функциональности оно было переписано на C.
     
     
  • 3.21, User294 (ok), 06:13, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге мало того что он тормозной что пипец, так еще и жирные пакеты с кучей зависимостей на low resource машинах (128 мегов RAM, etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну памяти видите ли не хватает - во новости! Да, блин, теперь 128 мегов (без иксов и с почти нифига в системе, где полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут городить тормозных прожорливых монстров на перле?
     
     
  • 4.23, PereresusNeVlezaetBuggy (ok), 09:42, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге
    >мало того что он тормозной что пипец, так еще и жирные
    >пакеты с кучей зависимостей на low resource машинах (128 мегов RAM,
    >etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну
    >памяти видите ли не хватает - во новости! Да, блин, теперь
    >128 мегов (без иксов и с почти нифига в системе, где
    >полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут
    >городить тормозных прожорливых монстров на перле?

    Во-первых, Perl далеко не настолько прожорливый, как Python. Во-вторых, можно и на сях написать такое гуано, что будет охренительно тормозить. Прежде всего — алгоритмы: код на Python с O(n) будет лучше кода на C с O(n!) на хоть сколько-то заметном количестве обрабатываемых объектов. Ну а на небольшом количестве (в случае с пакетным менеджером) вообще пофиг: вы заметите в его случае разницу между 0,1 с и 0,001 с? ;) В-третьих же, читайте внимательнее: Perl используется для упрощения внутренней логики. А упрощение оной приводит к меньшим проблемам в поддержке, что означает меньше багов. Вы предпочитаете программы, которые делают 1000 операций в секунду, на которые будет возникать в среднем пять ошибок, или 500, но всего с одной?

     
     
  • 5.28, User294 (ok), 13:27, 02/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Да, но при равных условиях один и тот же алгоритм реализованный не слишком кр... большой текст свёрнут, показать
     
     
  • 6.29, PereresusNeVlezaetBuggy (ok), 15:05, 02/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Напишете На сях Чисто для сравнения Теоретик , если вы посмотрите внимате... большой текст свёрнут, показать
     
     
  • 7.30, User294 (ok), 03:12, 03/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Да, умничать все сильны А почему бы не задать этот вопрос разработчикам вон той... большой текст свёрнут, показать
     
     
  • 8.31, PereresusNeVlezaetBuggy (ok), 12:21, 03/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    сорри, цитировать не буду, т к иначе получится ещё запутаннее Менеджер пакето... большой текст свёрнут, показать
     
     
  • 9.32, User294 (ok), 21:15, 03/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Это системный софт, делаемый 1 раз и надолго И в конечном итоге - переделывать ... большой текст свёрнут, показать
     
     
  • 10.33, PereresusNeVlezaetBuggy (ok), 21:49, 03/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Много фигни skipped Сравните http www debian org releases stable и http ... большой текст свёрнут, показать
     
  • 10.34, PereresusNeVlezaetBuggy (ok), 22:31, 03/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    сорри, забыл ответить Да, это установщик пакетов Работает на low-resource пла... текст свёрнут, показать
     
  • 4.24, kost BebiX (?), 10:28, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге
    >мало того что он тормозной что пипец, так еще и жирные
    >пакеты с кучей зависимостей на low resource машинах (128 мегов RAM,
    >etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну
    >памяти видите ли не хватает - во новости! Да, блин, теперь
    >128 мегов (без иксов и с почти нифига в системе, где
    >полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут
    >городить тормозных прожорливых монстров на перле?

    Yum стал лучше в федоре 12й, попробуйте (а плагин presto - это счастье для пользователей медленного интернета).

     
     
  • 5.25, Tav (?), 12:41, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Yum стал лучше в федоре 12й

    А в 11 чем был плох? И presto там есть (если установить yum-presto).

     
     
  • 6.26, kost BebiX (?), 13:00, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> Yum стал лучше в федоре 12й
    >
    >А в 11 чем был плох? И presto там есть (если установить
    >yum-presto).

    Нет, мне йум всяко нравится и сейчас, но в 12й федоре стал быстрее заметно.

     
     
  • 7.27, Slavaz (ok), 13:35, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Нет, мне йум всяко нравится и сейчас, но в 12й федоре стал
    >быстрее заметно.

    Неплохо. Он и в 11-й не медленный, а тут.. :)

     

  • 1.3, Oleole (?), 16:46, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а почему нельзя просто доработать мажорную версию АРТ? АРТ совсем помер уже что ли?
     
     
  • 2.5, Zenitur (?), 16:48, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное, это создаст изменения, сильно меняющие APT.
     

  • 1.4, Zenitur (?), 16:47, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Проблемы с архитектурой и реализацией - это какие? У меня не хватает мозга понять, видимо, это что-то маленькое но в итоге обидное.
     
     
  • 2.7, Андрей (??), 16:59, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Это проблемы мешающие добавлять новые фичи и исправлять ошибки без приведения кода в помойку.
     
     
  • 3.8, Аноним (-), 17:22, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это проблемы мешающие добавлять новые фичи и исправлять ошибки без приведения кода в помойку.

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

     
     
  • 4.17, Андрей (??), 00:12, 26/09/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Например, в этом баге намек на сложность его исправления. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542767
     

  • 1.16, Аноним (-), 21:54, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >написанной на языке Perl

    Спасибо, не надо.

     
  • 1.18, gogo (?), 23:24, 26/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А кто загрузит и поставит перл, если сделана минимальная инсталляция оси?.. Ручками?
    Зачем нужен менеджер пакетов, который сам зависит от десятков пакетов?
     
     
  • 2.19, PereresusNeVlezaetBuggy (ok), 23:30, 26/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >А кто загрузит и поставит перл, если сделана минимальная инсталляция оси?.. Ручками?
    >
    >Зачем нужен менеджер пакетов, который сам зависит от десятков пакетов?

    Либо это инсталляция на нормальный комп и поставить Perl — не проблема, либо это что-то типа встраиваемых систем, но тогда что там забыл менеджер пакетов? :)

     
     
  • 3.20, yurror (?), 12:51, 28/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    OpenWRT. что там забыл менеджер пакетов? О_о
    зачем сразу так категорично?
     
  • 3.22, User294 (ok), 06:20, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, а nokia Nxx0 или OpenWRT блаародный дон конечно не видел. Ну да, конечно, если делать по технологиям 80-х то конечно, можно и вовсе в ROM с ультрафиолетовым стиранием все шить.Только некрофилов знаете ли немного потому что гибкие и обновляемые решения нужны всем. Для начала - очень много добра работает с сетями. В частности обе упомянутых железки. И это означает что однажды они не будучи апдейтабельными попросту станут вкусными маленькими ботами. А миллиард комаров как известно поднимает в воздух слона. Не говоря о том что миллион роутеров начавших синхронно флудить вокруг - уронит все что роняется. Вы все еще считаете что манагеры пакетов блажь?Зря, 80-е закончились, 90-е прошли. И реалии нынче другие - орава хакерья ищет дыры везде, ради наживы на спаме и ддосах на конкурента.Так что по старинке уже во многих случаях не выйдет, реалии не те...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру