Jeff Johnson, один из разработчиков и руководитель проекта RPM, опубликовал (http://wraptastic.org/blog/?p=22) комментарии к недавно опубликованной статье (http://tweek.dyndns.org:8080/blog/20050613/top-ten-problems-...), в которой подчеркивается 10 главных проблем RPM.URL: http://wraptastic.org/blog/?p=22
Новость: http://www.opennet.me/opennews/art.shtml?num=5722
А мне понравилось, RPM рулит.
рулит make install clean
Согласен с редыдущим оратором. cd /usr/ports/*/* && make install clean
Долго однако.
apt-get install имя_пакета - быстрее.
> Долго однако.
apt-get install имя_пакета - быстрее. <А portinstall <имя пакета> - еще быстрее ;-)
А если еще и алиасов наделать, или вообще на сочетания клавишь комманды повесить - так вообще гиперскорость набирешь при установке софтин. ;-)Важно не то - сколько буков надо набить, а насколько адекватнен будет результат их набора, про что тут и речь. ;-)
emerge все равно лучше всех
emerge
revdep-rebuild
и т.д.Хотя я не говорил что там нет проблем;)
с точки зрения поддержания каталога 3rd party software, да, в портах FreeBSD на халяву и в актуальном виде есть то, что в линуксовых дистрибутивах обычно либо старое, либо по подписке (у RedHAT или SuSE попробуйте найти на халявую коллекцию свежих spec-ов, удавятся ведь)а с точки зрения здравого смысла у spec объективно больше преимуществ.
rpmbuild -bb имя_файла.spec - ничуть не сложнее, чем make intall :-)в RPM более аккуратно прописаны зависимости, это факт. RPM на уровне пакетного менеджера опять позволяет обновлять пакеты, pkg_upgrade - такого нету :-) собственно, два больших косяка налицо.
1) В RH вобще достаточно старые версии - но во всяком случае там ошибок меньше. Таже идеология в debian stable.2) для того что бы сделать rpmbuild -bb имя_файла.spec нужно еще разспаковать src.rpm. тогда уж вспоминай rpmbuild --rebuild $name.src.rpm.
А если хранить у себя только spec + патчи - то может быть лучше уж порты ? :)
src.rpm удобен тем что в его комплекте сразу и сходники идут..
На счет "акуратности зависимостей" вот официальный ответ от RH
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129875
Одна из основных проблем rpm (да и вобще любого пакетного менеджера под линухом) - если в post скритах будут использоваться вещи из пакетов которые уже стерты, но эта зависимость не отображена была - получим облом..3) portupgrade уже отменили?
portupgrade меня уже пару раз подводил когда зависимости не совсем корректно отрабатывал, хотя весчь достаточно мощная факт.
так же не совсем крут и portdowngrade тоже примерно в 10% случаев не спасает.
>portupgrade меня уже пару раз подводил когда зависимости не совсем корректно отрабатывал,
>хотя весчь достаточно мощная факт.Добавить еще ключик -R, чтобы уж наверняка. А еще лучше, перед этим сделать pkg_create -vb <полное имя установленного пакета>, создав пакет из уже установленой проги - чтоб потом можно было легко и безболезненно вернуть взад старую версию. :-)
> что в линуксовых дистрибутивах обычно либо старое,a-la fedora ?
> либо по подписке (у RedHAT или SuSE попробуйте найти на халявую
> коллекцию свежих spec-ов, удавятся ведь)srpm'ки в свободной доступности - берите и пересобирайте (закрыты только бинарные пакеты) :)
ЗЫ. Так что - неправда Ваша. Не знаете, а говорите.
аргумент насчет необходимости иметь в нагрузку к spec файлу распакованный src.rpm - скорее от нехватки опыта :-)всю жись собираю php и apache из spec-ов, пока что src.rpm не требовалось. хз, может что-то неправильно делаю, наверное.
так что, почему SuSE не выкладывает в cvs/cvsup репозиторий коллекцию актуальных spec-ов (и паччей к исходникам) - фиг знает, наверное от жадности. а то было бы как в коллекции портов под фри.
насчет portupgrade - хм, а я могу уже собранный пакет при помощи этой штуки накатить ? то есть, по аналогии
rpm -U xyz1.rpm xyz2.rpm ... xyzN.rpm
такое ТОЧНО можно сделать на фри при помощи portupgrade ?
насчет прописывания зависимостей на фри и в RPM, в собранном пакете samba будет явно указана зависимость от той версии openldap, с которой он компилировался, а не с библиотекой liblber.so.2 например, и не с openldap >= 2.2.26, в этом самое палево и есть.
>насчет portupgrade - хм, а я могу уже собранный пакет при помощи
>этой штуки накатить ? то есть, по аналогии
>
>rpm -U xyz1.rpm xyz2.rpm ... xyzN.rpm
>
>такое ТОЧНО можно сделать на фри при помощи portupgrade ?$ man portupgrade
...
-P
--use-packages Use packages instead of ports whenever available.
portupgrade searches the local directories listed
in PKG_PATH for each package to install or upgrade
the current installation with, and if none is
found, pkg_fetch(1) is invoked to fetch one from a
remote site. If it doesn't work either, the port
is used.-PP
--use-packages-only Never use the port even if a package is not avail-
able either locally or remotely, although you
still have to keep your ports tree up-to-date so
that portupgrade can check out what the latest
version of each port is....
Читайте маны, они рулез.
1) видимо в твоих spec не было патчей. Таки да без патчей можно один spec держать :) А если там есть патчики ? :) Которые еще и не подоходят к новой версии программы? :)2) собраные пакеты можешь. Цитата из man portupgrade
-PP
--use-packages-only Never use the port even if a package is not avail-
able either locally or remotely, although you
still have to keep your ports tree up-to-date so
that portupgrade can check out what the latest
version of each port is.3) Пишите правильно spec и все будет зашибись. Все это можно указать - было бы желание, которого увы у большинства spec писателей нету.
Здорово. Вот это комментарии. Хороший пример того как любитель критиковать нарвался на профессиональное знание предмета.
А ещё мне понравился английский, не знаю откуда автор родом, но язык хороший.
кто-нибудь прикручивал к фре? кстати об RPM. Понимаю, что не нужно, просто интересно, как apt на фре будет работать...
Прикрутить можно.. но нафига? возмешся конвертировать все порты в spec ? :)