В статье рассказывается о так называемой "войне форматов установочных пакетов" и рассказывается о том, какое возможно будущее будут иметь пакетные инсталяторы в Linux
Дык вроде какие-то ребята собирались api писать для различных пакетных систем?
Вообще тема, считаю, не очень актуальна для (опытных) пользователей Линукса. Да, было бы приятно, но не более того. Особых проблем по этому поводу не испытываю.. и не предлагайте мне поговорить об этом.. =))
Статья кошмарная.. Там явно намекают, что неплохо бы, если бы в линуксе основная масса софта бралась не из централизованных поддерживаемых разработчиками дистрибутивов источников - с жестко определенной политикой, контролем, etc, а от кого попало, а идеальная "система пакетов" должна контролировать связывание всяких разных софтин. Да пошли бы они куда подальше с такими предложениями! rpm (deb, portage, etc) рулят, а autopackage с click-and-run на мыло!
Не надо кричать с такими красными глазами, анонимный брат. Portage, разумеется, наше всё, но и .deb - очень хорошая, годная система для бинарных пакетов.
Ну а вот что rpm посещает топку спорить не буду, ибо это истинно так.
RPM-очень сложный, запутанный формат. У DEB же, мой "друк", структура проста и понятна. А portage-это вообще песня, такого простого и одновременно очень мощного формата, как у ебилдов, я ёще никогда не видел! (говорю без всякого фанатизма)
> человек, вкусивший плод удобства работы с apt-get + deb никогда не будет добровольно работать с rpm
Хм. А я вот "вкусил плод удобства работы с apt-get + deb" и радостно продолжаю работать с rpm + yum :) А вообще, deb хорош, но у него есть свои недостатки. Сборка пакетов под разные архитектуры и оптимизация под конкретные типы процессоров в rpm, например, лучше поддерживается (rpmbuild --rebuild --target=athlon пакет.src.rpm).
> человек, вкусивший плод удобства работы с apt-get + deb никогда не будет добровольно работать с rpm
Вот как? А я, почти четыре года проработав с дебианом (и пару месяцев пострадав со слакой), с огромным удовольствием перешел на редхат (хотя на тот момент yum еще не существовал), и считаю, что человек, поработавший с rpm, с его строго формализованным и управляемым процессом сборки, никогда не перейдет на ворох самописных костылей, которые нужно друг с другом связывать, имя которым - deb-пакеты...
К тому же, пакеты - еще не все, важен дистрибутив. У debian'а слишком много принципиальных недостатков из-за особенности его политики, ubuntu с одной стороны тяготит наследие дебиана, с другой стороны - много своих неприятных приколов. А других дистрибутивов толком и нет, выбирать не из чего! Среди rpm-based дистрибутивов вариация куда больше, каждый выбирает на свой вкус. От CentOS до Fedora, полную альтернативщину в виде SuSE, ну и множество более специализированных дистрибутивов.
> оптимизация под конкретные типы процессоров в rpm, например, лучше поддерживается (rpmbuild --rebuild --target=athlon пакет.src.rpm).
Не знаю, как с этим в дебиане, но в rpm собирать multiarch-пакеты та еще песня.. Без 32-х битного chroot'а (что само по себе крайнее извращение), в полноценной multiarch x86-64 системе собирать некоторые пакеты для i386 просто мерзко, а некоторые - практически нереально. Только mock и прочие костыли для временного создания chroot-окружения на время сборки и спасают в таких случаях...
> ...считаю, что человек, поработавший с rpm, с его строго формализованным и управляемым процессом сборки, никогда не перейдет на ворох самописных костылей, которые нужно друг с другом связывать...
газификация луж проведена успешно. ;)
Может мсье объяснит, чем его _реально_ неустраивает DEB?
> Хоть бы объяснили внятно, чем эти autopackage и CnR так хороши.
А чего плохого когда поставив под дистрибутивом Autopackage можещь легко установить любой из пакетов для него, и так=же легко его деинсталлировать. Но Linux это ведь не Windows - сейчас уже (и слава Богам) можно легко родными средствами rpm/deb-дистрибутивов обойтись.