Один из разработчиков Debian и Ubuntu сообщил (http://juliank.wordpress.com/2009/08/24/the-apt2-project/) о начале работы над проектом по написанию замены для системы управления пакетами APT. Главная идея нового проекта, получившего название APT2, - создание библиотеки для управления пакетами и работы с репозиториями, поверх которой будет организована работа стандартных сервисных утилит. Иными словами APT2 отличается от APT своей ориентацией на библиотечную подсистему, в то время как APT сосредоточен вокруг конечных приложений.
Для написания APT2 выбран развиваемый разработчиками GNOME язык программирования Vala (http://ru.wikipedia.org/wiki/Vala), который обладает простым синтаксисом (похож на C#) и дает возможность использования функций библиотеки GLib (например, работа с unicode строками, обработка файлов, создание контрольных сумм и т.п.). Исходные тексты на языке Vala транслируются в код на языке Си, которые в дальнейшем обрабатываются как обычные Си-приложения.
В качеств...URL: http://juliank.wordpress.com/2009/08/24/the-apt2-project/
Новость: http://www.opennet.me/opennews/art.shtml?num=23176
/me чувствует , что это закончится так же, как и grub2
А что с ним?
>А что с ним?а туда скоро ядро Linux встроят, всё к тому и идёт.
как?
>закончится так же, как и grub2А чем закончился grub2?
тем чтоне работает.
странно, как же это я с ним два года живу уже, да и вон в убунте он по умолчанию будет.
вообще-то работает
У меня работает. ЧЯДНТ?
Только что в какой-то из соседних веток о 0install писали...
Идея неплохая. Только займет это у дебианщиков годы. И правильно. В процессе можно будет на кошк^W убунтоводах потренироваться.
Хорошо, что кто-то еще нативный софт пишет, а не дерьмо на интерпретируемых языках. Нет, я против них ничего не имею, но никак не для низкоуровневых вещей. Хотя vala тот еще костыль, лучше бы на C++.
Чем лучше ?
Посмотрите в Gentoo. Система по сути базируется на Python, который входит в небольшой список базовых пакетов system. Теперь посмотрите что вам предлагают установить тут. Glib! А теперь посмотрите на встраиваемые решения и убедитесь, что поддержка Python у многих из коробки, тогда как GTK никто даже и не пробовал для них скомпилить.Тем не менее я за (хоть и не использую deb-дистрибутив). Vala требует обкатки прежде чем кто-то на нём станет писать. APT как раз подойдёт для экспериментов :)
Glib != gtk, это так, для начала.
Также gentoo из-за не самой лучшей реализации на питоне - довольно медлительно ворочается. Элементарный emerge --search должен работать мгновенно, но занимает секунды. Тут конечно виноват не только питон.
Ну и конечно питон ни чем не легче glib, а для дистрибов типо debian, gentoo и тд - без разницы что пихать в базу, питон ли, glib ли. Главное чтобы результат был хороший. Пожелаем им успехов.
use eix, Luke
А paludis реактивен. Да и питоний zypper под opensuse - тоже.
Господа, я понимю что юзать. Речь шла как бы именно о родных утилитах дженты. Именно они на питоне. Хотя ещё раз повторюсь там тормоза не только из-за питона.
Но причин писать системные утилиты на питоне я не вижу, ни одной.
>Но причин писать системные утилиты на питоне я не вижу, ни одной.а на чём? на си, что ли? вообще-то у никсов есть давняя традиция писать всякие подобные вещи как раз на скриптах. а на си — только какие-то совсем уж time critical вещи.
зыж но бидон я не люблю, да. потому генту и не ставил.
Чем плох glib ?
>А теперь посмотрите на встраиваемые решения и убедитесь, что
>поддержка Python у многих из коробки,Смотрю. Например Nokia n800 (хоть и не то чтобы встраиваемое, но ограниченное в ресурсах решение). Apt вижу. И даже GTK из коробки есть. Но питон надо доустанавливать, если он нужен. Или вот мой WL500GP. Там вообще манагер пакетов облегченный opkg :P. И упаси меня боже на такой железке запускать питон - он половину оперативки только под свой долбаный интерпретер сожрет. Не говоря уж о том что yum писаный на оном yum стушевался на виртуалке с 128 мег оперативы. Что же будет если байду на питоне запустить на встраиваемом решении - роутере, у которого на все 32 мега из коих половина уже забита сетевыми сервисами?! Я вообще не смогу заинсталировать ни 1 пакета по причине окончания памяти до того как пакеты установятся? oO К слову, питона там тоже нет. По дефолту - точно. Можно ли поставить - а хрен знает - нафиг мне питон на железке с 32 мег памяти?
> Нет, я против них ничего не имею, но никак не для низкоуровневых вещей.Однозначно! Знаете как удивились чуваки которые yum-ом попытались на виртуалку поставить обыкновенный такое PHP? Этому говну на питоне... 128Mb памяти - НЕ ХВАТИЛО. В системе где кроме оного почти ничего не работало (ssh и еще пара не слишком жирных демонов). Охренеть.
>Хорошо, что кто-то еще нативный софт пишет, а не дерьмо на интерпретируемых
>языках. Нет, я против них ничего не имею, но никак не
>для низкоуровневых вещей. Хотя vala тот еще костыль, лучше бы на
>C++.
Эй, я не писал этот комментарий!
в apt не хватает проверки скаченного с md5 и torrent
> в apt не хватает проверки скаченного с md5 и torrentДавайте скажем проще — Metalink ему не хватает. Качает-то все равно не apt.
Алсо, подписи и контрольным суммы пакетов проверяются. Или я чего-то не понимаю?
>> в apt не хватает проверки скаченного с md5 и torrent
>
>Давайте скажем проще — Metalink ему не хватает. Качает-то все равно не
>apt.
>
>Алсо, подписи и контрольным суммы пакетов проверяются. Или я чего-то не понимаю?
>я не в курсе что там проверяется, но пакеты частенько скачиваются битые
> в apt не хватает проверки скаченного с md5 и torrentapt-transport-debtorrent:
Description: an APT transport for communicating with DebTorrent
This package contains the APT debtorrent transport. It makes it possible to
use 'deb debtorrent://localhost:9988/foo distro main' type lines in your
sources.list file.не оно ?
>> в apt не хватает проверки скаченного с md5 и torrent
>
>apt-transport-debtorrent:
>Description: an APT transport for communicating with DebTorrent
> This package contains the APT debtorrent transport. It makes it possible
>to
> use 'deb debtorrent://localhost:9988/foo distro main' type lines in your
> sources.list file.
>
>не оно ?а вот за это огромное спасибо!!!
Apt-p2p наше всьо
> Иными словами APT2 отличается от APT своей ориентацией на библиотечную подсистему, в то время как APT сосредоточен вокруг конечных приложений.Что-что? APT вообще не различает приложения и библиотеки дальше понятия категорий, на которое все инструменты его уровня плевать хотели и оно больше информативное, для aptitude/synaptic/...
Не об этом речь, читать научитесь.
речь о том, что apt2 - будет набор библиотек для работы с пакетами, тогда как apt - это набор конечных приложений...
гы... дебиянщеки устали от старых костылей и решили сделать новые. видать aptitude тоже неудачной попыткой переписать apt оказалась
>видать aptitude тоже неудачной попыткой переписать apt оказаласьне путайте userland с core.
mike lee похоже управляет своими пакетами руками, потому что в его слаке ничего нету. Пакетная система debian'a одна из самых совершенных.
>mike lee похоже управляет своими пакетами руками, потому что в его слаке
>ничего нету. Пакетная система debian'a одна из самых совершенных.кроме слаки и дебиан бэйзед (и прочего rpm как с apt-rpm так и без оного) в мире есть еще много интересного. имхо portage куда как более совершенен.
> Пакетная система debian'a одна из самых совершенных.С ублюдскими suggests/recommends и тормозами? Очень сомневаюсь. А "самой" совершенной _бинарная_ система пакетов быть в принципе не может.
>С ублюдскими suggests/recommendsА что в них ублюдского? oO
> и тормозами?
Это говорит поклонник source based систем?! Знаете, дебианский пакетный манагер вкатит пакет быстрее чем он у вас перекомпилируется на том же железе. Как ни крути. И побыстрее ряда других пакетных систем.
>А "самой" совершенной _бинарная_ система пакетов быть в принципе не может.
А по-моему у дебианщиков очень даже грамотно - если за каким-то хреном надо перекомпилить некий пакет (скажем, параметры другие задать) - так это у дебианщиков просто и автоматизированно, блин. Вот только в отличие от source based это не "с ножом к горлу" а "по желанию". Что в случаях когда время важнее эстетства - очень ценно.
> Это говорит поклонник source based систем?! Знаете, дебианский пакетный манагер вкатит пакет быстрее чем он у вас перекомпилируется на том же железе.Да вот нет. Пакет, который не надо собирать FreeBSD установит моментально, пока ваш apt будет читать базу да какие-то там hook'и выполнять. На перловых модулях очень заметно.
> Только что в какой-то из соседних веток о 0install писали...Вот вот, я тоже это читал. Может я что-то не понимаю (да, APT и .deb лучшее что сейчас есть), но все таки недостатки есть. И только 0install-подобная система управления пакетами позволит уйти навсегда от ограничений, типа одновременной установки одной версии библиотеки с модификациями, блокирования обновлений, затрудненная установка сторонних пакетов, дистрозависимость, трудность переноса программы с компьютера на компьютер и т.д.
Устанавливать для каждой программы необходимые ей библиотеки как минимум не экономно с точки зрения распределения пространства жесткого диска. Кроме того одинаковые динамические библиотеки, находящиеся в разных местах - это разные библиотеки, что с точки зрения памяти тоже не айс.
Можно запустить демона, коооорый будет проверять запрошенные библиотеки на одинаковость и держать по копии для каждой. Конечно, это будет уже не совсем 0install, но вполне реализуемо и уже реализовано в Nix.. Вопрос в том, стоит ли отсутствие понятия конфликта пакетов (я могу поставить А и я могу поставить Б => я могу поставить А и Б) и возможность быстрого отката изменений недостатков - то есть необходимости обновить всё зависящее от библиотеки при её изменении. Лично для меня ответ - стоит.
>Можно запустить демона, коооорый будет проверять запрошенные библиотеки на одинаковость и держать по копии для каждой.можно и ещё кучу методов придумать. например, общее хранилище библиотек и проверка md5/sha при установке. совпали? симлинк. не совпали? кладём файл. нет вообще? в хранилище и симлинк. вот и демона не надо, например.
О, т.е. теперь еще и установка будет не быстрой. А потом обновляем пакет на который ссылаются все симлинкующиеся и получаем ту же ситуацию, что и в данный момент, когда обновляется все. А если нет разницы, то зачем качать больше?
>О, т.е. теперь еще и установка будет не быстрой. А потом обновляем
>пакет на который ссылаются все симлинкующиеся и получаем ту же ситуацию,
>что и в данный момент, когда обновляется все. А если нет
>разницы, то зачем качать больше?какой «пакет», дарагой? съешь таблеточку, успокойся, может, у тебя подумать выйдет. *кто* позволит перезаписывать библиотеку в хранилище, а? ну, обновил ты софтину. ну, приволокла она новую библиотеку. ура — новая либа welcome в хранилище либ. старая — ВНИЗАПНА! — никуда не делась. теперь покажи, как тут что-то сломается, а?
поскольку твой умственный уровень у меня вызывает определённые сомнения (в смысле — наличие оного), то я поясню: хэши библиотек тоже можно хранить на винте, а не считать каждый раз. и в пакете хранить. где тут тормоза, а? спросить у центральной базы «дорогая, а есть ли у тебя библиотека вот с таким вот хэшем?» ну, если у тебя и ТАКОЕ тормозит — то выкинь свой MK-62.
да, для альтернативно одарённых: библиотеку из хранилища можно выкидывать, когда снесены все ссылающиеся пакеты. а можно и не выкидывать. а для девелоперов можно предусмотреть дополнительные опции — типа «сканировать весь диск на предмет линков» (благо, locate и так базу строит, дело недолгое).
уловил?
А блокнот зависимый от kdelibs будет в пакете содержать весь kde?
>А блокнот зависимый от kdelibs будет в пакете содержать весь kde?Да ну их в сад с их стремными методами. У дебианщиков вполне нормальные пакетные манагеры которые вполне себе справляются с своими задачами. А устаревание софта в общем то не вина манагера пакетов а на совести майнтайнеров.
>Да ну их в сад с их стремными методами. У дебианщиков вполне
>нормальные пакетные манагеры которые вполне себе справляются с своими задачами. А
>устаревание софта в общем то не вина манагера пакетов а на
>совести майнтайнеров.Ну вообще-то идея снять некоторые вещи с совести роддерживающих пакеты очень неплоха. Ещё лучше идея, что как можно больше видов серьёзных ошибок должно приводить к очевидной неудаче, а не к мелким пакостям.
Я тоже думал, что apt-get со всем справляется, и огорчился, когда при небольшом обновлении sid он захотел:
1) обновить glibc
2) снести из-за несовместимости с новой glibc старые xlibs
3) остановиться, не ставя новые пакеты для все
>А блокнот зависимый от kdelibs будет в пакете содержать весь kde?Только зависеть. Если kde уже установлен - то блокнот его использует.
>да, для альтернативно одарённых: библиотеку из хранилища можно выкидывать, когда снесены все
>ссылающиеся пакеты. а можно и не выкидывать. а для девелоперов можно
>предусмотреть дополнительные опции — типа «сканировать весь диск на предмет линков»
>(благо, locate и так базу строит, дело недолгое).Сканировать не надо, зачем. Есть просто сообщение для базы "я использую это пакет и положил ссылку сюда". Проверить достаточно зарегистрированные места со ссылками.
Демон нужен. С ним пользователи должны верить только root (и тем, кого root публично добавил в список доверия). То есть если пользователь хочет "пакет, собранный вот так" - он его получит. Возможно с бинарного репозитория, добавленного root. Если другой пользователь хочет тот же пакет - он получит ссылку на установленную копию. Если пользователь хочет пакет с тонной вирусов - он его тоже получит для личного пользования, но не сможет подложить его другому пользователю как хороший. Для этого и нужен демон - права записи в хранилище только у него.
вместо того чтобы обновить одну либу libpng например Вы предлагаете обновлять все пакеты её использующие ? гениально ! :)
От этого позволяет уйти source-based система, а для бинарных пакетов вы только и будете что городить костыли, демоны, да симлинки. Я на FreeBSD десктопе сижу года 4 с 3000+ установленными пакетами последних версий - и НИКОГДА не встречал проблем с обновлением. Почему в Linux нельзя также?
Потому что все программы раздроблены на мелкие пакеты (особенно это касается deb дистрибутивов). Наверное, такой подход очень экономит место на современных бездонных дисках, чем-то упрощает жизнь девелоперам, но вот поэтому-то и нельзя. Что бы обновить какую-нибудь перделку-сопелку, то может потребоваться перевести stable всего дистрибутива в состояние testing+stable. А если мантейнер пакета возмет и build-depends "причешет, лишь бы стработало" под ветку testing, то с такими зависимости на stable может вообще все плохо кончится.
>дистрибутива в состояние testing+stable. А если мантейнер пакета возмет и build-depends
>"причешет, лишь бы стработало" под ветку testing, то с такими зависимости
>на stable может вообще все плохо кончится.Ужас, как дебиланщики живут. На source based нет никаких stable/unstable/testing, а все гораздо стабильнее, удобнее и при этом новее.
Vala (похожий на шарп) с GLib, да ещё и развиваемый GNOME... Ужас.
Как бы не оказался очередной микрософтовский мигрант, который не смог разобраться с APT и потому решил написать свой.Пугающая тенденция. Очень хочется ошибаться и верить, что на самом деле всё наоборот и это просто я не разобрался...