Clement Laforet сообщил (http://lists.freebsd.org/mailman/htdig/freebsd-ports/2005-No...) о включении нового make сценария bsd.apache.mk в дерево портов FreeBSD.Дополнительно были включены ещё два сценария: bsd.database.mk и bsd.tcl.mk. Мэйнтейнерам портов рекомендуется изучить их содержимое. Так же, одним из изменений было введение в описание портов дополнительной к MD5 контрольной суммы - SHA256.
URL: http://lists.freebsd.org/mailman/htdig/freebsd-ports/2005-No...
Новость: http://www.opennet.me/opennews/art.shtml?num=6411
Криво как-то это sha256 добавлено !
Если в системе нет бинарика /sbin/sha256 или /usr/local/sbin/sha256, то никакого счастья не будет.
Бинарик же /sbin/sha256 есть только в FreeBSD 6.0
>Криво как-то это sha256 добавлено !
>Если в системе нет бинарика /sbin/sha256 или /usr/local/sbin/sha256, то никакого счастья не
>будет.
>Бинарик же /sbin/sha256 есть только в FreeBSD 6.0Нашел - есть порт sysutils/freebsd-sha256 !
Он добавляет бинарик /usr/local/sbin/sha256
Недавно в портах зависимости от этого порта стали проставлять.У меня на FreeBSD 5.4 теперь SHA256 проверяется.
сразу видно делетант - иначе бы знал что дерево портов развиваеться для каждой ветки отдельно
Это Вам кто такое сказал???
Дилетант 100%. Только Аноним :(
Дерево портов одно и абсолютно не зависимо от веток base system. Единственно, packages собираются на каждую систему отдельно. Но дерево как ни крути одно.
Видимо человек с openbsd - там рекомендуют пользоваться _только_ сборками - никаких этих самых кампиляций - типа, не серьёзно это, програмки на сервере компилить
ещё два сценария: bsd.database.mk и bsd.tcl.mk
что это такое и на что это влияет ?
bsd.database.mk - для mysql, postgresql & bdbВлияет только на скорость сборки портов - просто разные части из bsd.port.mk вынесли в отдельные файлы.
/usr/ports/Mk/ весит уже 410 Kb
умные вы все я как по смотрю...
а теперь телаем cvsup и меняем там таг
>умные вы все я как по смотрю...
>а теперь телаем cvsup и меняем там тагНу и - какой таг меняем и на что ?
Порты в CVS лежат без веток. Тагами же маркируются порты для определенных релизов. Именно маркируются, а не создаются новые ветки.
>>умные вы все я как по смотрю...
>>а теперь телаем cvsup и меняем там таг
>
>Ну и - какой таг меняем и на что ?
>Порты в CVS лежат без веток. Тагами же маркируются порты для определенных
>релизов. Именно маркируются, а не создаются новые ветки.odip - 100%
идем например сюда:
http://www.freebsd.org/releases/4.9R/schedule.htmlи читаем:
Ports tree tagged 23 Sep 2003 24 Sep 2003 RELEASE_4_9_0 tag for ports/.А потом если интересно то читаем доку по CVS раздел Sticky tags.
А если по русски, если стянуть порты с tag RELEASE_4_9_0, то твое дерево портов будет соответствовать состоянию дерева на момент выхода 4.9 REL, т.е 23 Sep 2003. Если тебе надо откатиться назад до этого состояния (например поставить софт который тогда был самый новый) - то это оно, а если тебе надо быть up2date то на всех ветках base system тебе надо update портов делать до tag=.
>А если по русски, если стянуть порты с tag RELEASE_4_9_0, то твое дерево портов будет соответствовать состоянию дерева на момент выхода 4.9 REL, т.е 23 Sep 2003. Если тебе надо откатиться назад до этого состояния (например поставить софт который тогда был самый новый) - то это оно, а если тебе надо быть up2date то на всех ветках base system тебе надо update портов делать до tag=.Не, ну это конечно можно сделать. А смысл?
Ты получишь устаревшее ПО даже без security fixes.
Теги в портах служат единственной цели - сборки пакаджей для релизов.
И рекомендовано на всех релизах пользоваться tag=. Официально поддерживается только это.Есть неофициальнае ветка: http://ports.bsdlab.org/
kuriyama по мере сил поддерживает ее в безопасном состоянии. Он называет ее Security Branch. Эта ветка предназначена для тех, кто не хочет постоянно обновляться, а поставить ПО один раз и дальше не трогать, отслеживая только заделку обнаруженых дыр.
Но понятно, что он один не в состоянии поддерживать все дерево портов, а людского ресурса не хватает.Создание бренчей не раз обсуждалось, но недостаток аппаратных ресурсов был призван основной проблемой. Как людских, так и аппаратных: CVS депозитарий будет раздуваться и раздуваться с каждым бренчем и работать с ним будет все труднее и труднее.
>
>Создание бренчей не раз обсуждалось, но недостаток аппаратных ресурсов был призван основной
>проблемой. Как людских, так и аппаратных: CVS депозитарий будет раздуваться и
>раздуваться с каждым бренчем и работать с ним будет все труднее
>и труднее.Так людских или аппаратных ? :)
Насколько я понимаю в работе CVS создание branch не влечет за собой практически никаких расходов - там только тег в файле добавляется и все. Собственно говоря просто наличие десяти версий одного файла - это гораздо большие расходы чем создание branch.
Интересно когда будет переход с CVS на SubVersion или что-нибудь аналогичное.
Неплохо. Добавили net-im, удалили 108 портов старья, screen перенесли в sysutils :)