В текущую кодовую базу Fedora Linux интегрирована (https://www.redhat.com/archives/fedora-devel-list/2008-July/...) альфа версия новой редакции пакетного менеджера RPM, который в Fedora 10 должен прийти на смену RPM 4.4.2.3. Изменения в новой версии RPM ожидаются существенные, что отрицательно скажется на обратной совместимости пакетов.
Некоторые изменения:
- Значительное изменение API;
- rpmbuild по умолчанию использует "--fuzz=0" для наложения патчей, что может потребовать переработки большого числа пакетов;
- %{_topdir} теперь указывает на $(HOME)/rpmbuild/, а не на /usr/src/redhat/;
- BuildRoot из spec игнорируется, в качестве корня для сборки теперь используется %{_topdir}/BUILDROOT/;
- Реализована поддержка привязанных к аппаратной архитектуре зависимостей;
- Автоматическое разрешение зависимостей, связанных с pkg-config и libtool;
- rpmbuild поддерживает два новых макроса: %{patches} и %{sources}.
URL: https://www.redhat.com/archives/fedora-devel-list/2008-July/...
Новость: http://www.opennet.me/opennews/art.shtml?num=16885
а вот это уже давно пора. а то не понятно как в обще с такой тормозной системой сидели.
З. Ы.
Ни чего личного. У меня Debian. :)
Вы о чём? Сам по себе rpm вполне шустр, dpkg в сравнении -- якорь.
Можно пронаблюдать, скажем, по времени вливания одного CD пакетов.А так да, и rpm подзавалялся, и в макронаборах скорее разброд и шатание.
Причём у самих редхатов -- ещё и нищета ужасающая.Давно пора :-)
>Причём у самих редхатов -- ещё и нищета ужасающая.Мало того что изначально RPM по сравнению c dpkg просто уродец, так еще это постоянно перетрясают.Здорово отбивает охоту иметь дело с redhat-based системами.Да-да, это кстати и вашей системы касается.Пока она будет основана на редхате я к ней на пушечный выстрел не подойду.А "на подумать" - посмотрите на чем как правило основываются все новые системы ;)
+1
> Вы о чём? Сам по себе rpm вполне шустр, dpkg в сравнении -- якорь.
> Можно пронаблюдать, скажем, по времени вливания одного CD пакетов.Совершенно некорректно сравнивать сами утилиты,
так как они выполняют правила (скрипты),
созданные разработчиками пакетов.
А политика в области автоматизации установки
и стремлению(пределов) к дружественности к пользователю,
у deb-based и rpm-based дистров сильно отличается.
Частично это объясняется форматом пакетов,
частично policy дистрибутивов, остальное - самим разработчиком пакета.Сравните кол-во строк {pre,post}{in,un} скриптов в каком-нибудь "сложном"
rpm (например, в phpMyAdmin и ему подобных) с кол-вом строк
в {pre,post}{install,rm} deb-a.
Поэтому, после установки/обновления/апгрейда/отката на предыдущую версию
в Debian/Ubuntu даже "большие" программы-монстры становятся/остаются
в работоспособном состоянии, а в rpm-based дистрах зачастую нужны некоторые
ручные действия (базу обновить, пользователей завести, что-то в конфе поменять).
> а вот это уже давно пора. а то не понятно как в обще с такой тормозной системой сидели.О господи.Как раз за что не люблю redhat-based системы так это за тотальный бардак с RPM, разными версиями RPM, постоянные перетрясы и прочая.И так там черт ногу сломит, а они еще и перетрясают оный с завидной регулярностью.Ужас!
Сломается совместимость?Идите в зад!Это хучшее что может сделать дистроклепатель и это простительно только если слом несет реальные, неоспоримые преимущества стоящие того.
> Ни чего личного. У меня Debian. :)
Юзаю убунту и дебиан.Как раз в том числе по причине что пакетный манагер там сразу изначально нормальный и его не перехреначивают тотально каждый раз.
а ты что, используешь в реальной работе rawhide ветку? Почему вообще дебианщики так возбудились, когда люди у себя в альфа-версии новшества испытывают?
Поздравляю! Главное чтоб ничего не поломали (всмысле "незаметно для обычных юзеров").
Всё равно RH/Centos 5.x будет ещё ОЧЕНЬ долго жить. И клепать придётся рпм-ки под них...
хз че там перетрясают, вроде все работают и проги из рпмок ставяться без проблем, а с юмом так и с зависимостями.
> %{_topdir} теперь указывает на $(HOME)/rpmbuild/, а не на /usr/src/redhat/;
>BuildRoot из spec игнорируется, в качестве корня для сборки теперь используется %{_topdir}/BUILDROOT/;А что мешало раньше это переопределять? Если не ошибаюсь, то у альтов именно так и сделано. Да и BUILDROOT, если не ошибаюсь, сейчас задается относительно %{_tmpdir}
P.S. Юзаю Debian, но создание ./debian/* до сих пор не осилил, в отличие от .spec`ов.
>P.S. Юзаю Debian, но создание ./debian/* до сих пор не осилил, в
>отличие от .spec`ов.dh-make ? -- как база
>P.S. Юзаю Debian, но создание ./debian/* до сих пор не осилил, в отличие от .spec`ов.а мне как раз показалось проще моздание ./debian/*, чем .spec-ов
Ох недают лавры RPM покоя дебианщегам, вон как они тут разошлись, а воз и ныне там...*RPM*
Лавры rpm? Это что-то новенькое...
нужно сделать хотя бы такую же простоту установки пакетов
(и их совместимость) как в винде.
Да... Как я помню расстроился, когда скачал пакет, вроде как заточенный по мой дистр, пришел домой (дома инета нет), а он еще какой-то пакет захотел... Windows-кая логика не работает - там подразумевается, что если ты скачал программу, то кроме нее ничего не нужно (есть, конечно, исключения, например, проги под Frame Work).
В винде как таковых пакетов нет.Каждая программулина заново в свой каталог ставит теже пакеты... библиотеки
>В винде как таковых пакетов нет.
>
>Каждая программулина заново в свой каталог ставит теже пакеты... библиотекиесть Windows Installer
Это попытка Microsoft сделать сделать пакетный mananger
Люблю правильный линукс... Вот BSD - правильный линукс.
> Вот BSD - правильный линукс.улыбнуло =)
Я чего-то не осилил - это они полумёртвый rpm-4 перетрахивают или на rpm-5 наконец-то переходят?
> Реализована поддержка привязанных к аппаратной архитектуре зависимостей;то что в Debian есть сто лет, ВНЕЗАПНО появилось и у RH. Ура?
Why not RPM 5.0?Here's a changelog: http://wiki.rpm.org/Releases/4.5.90
>Why not RPM 5.0?
>
>Here's a changelog: http://wiki.rpm.org/Releases/4.5.90Why not dpkg?
RPM проще и лучше любого DEB
Как паз дебом можно сломать всю систему
Ох чую десяточка станет конфетой. Не сглазить бы))