http://mirror.yandex.ru/slackware/slackware-14.0/UPGRADE.TXT

slackpkg update && slackpkg upgrade-all

Для свежего софта есть git clone && src2pkg

Смотрел. И http://mirror.yandex.ru/slackware/slackware-14.0/CHANGES_AND_HINTS.TXT тоже.

Интересует логика, частота обновлений. Что будет, если что-то собрал сам. Следит ли кто за security-обновлениями, или надо самому просматривать новости на эту тему.

генерируем новый список зеркал для slackpkg
slackpkg new-config
­ В /etc/slackpkg/mirrors раскомментируем одно зеркало (не подошло
выбираем другое)
­ Обновляем базу пакетов
slackpkg update
­ Обновляем сами пакеты
slackpkg upgrade-all

И как потом себя собранный и установленный пакет ведет?

Как решаете, когда его обновлять?

http://software.jaos.org/

Я же в посте спросил не про замену

sudo aptitude update
sudo apttude upgrade

sudo pacman -Suy

да и вообще стремление к обновлениям ради самих обновлений это вообще то не слака, стоит, работает как надо, ну и пускай стоит, чего себе голову заморачивать.

Как решаете, когда его обновлять?

Когда не хватает функциональности — смотрю в ченжлоги новых версий, если добавили это — обновляю..

Мм, какую еще логику ? Появилось новое обновление, обновляешься, если уж так охота, следить за сами обновлениями можно через slapt-update-service, но, еще раз, в слаке вообще то не принято делать обновления ради самих обновлений, стоит, работает как надо, ну и пуская стоит. , в ней нет гонки арча

Инкрементирую.

Когда решим, тогда и обновляем. Твой Кэп.

Само по себе ничего обновляться не попросит и скачивать чего-то там в фоне тоже не будет.

Пакеты обновляют обычно либо при личной необходимости (нужна новая версия софта, например, обновлённый cmake). В целом можно обновляться и один раз в год-два при выходе очередного релиза, хотя это может не всегда получаться. Сиденье на current ничего особого не даёт. Обновления иногда раз в неделю, а иногда месяцами вообще ничего.

Отдельных security обновлений нету. «Просто чтобы было» в слаке пакет никто не обновит (я говорю об официальных пакетах). Поэтому за безопасность особо можно не переживать. Обратная сторона этого - некоторые вещи могут появится и позже других дистрибутивов (BackTrack вроде бы из-за этого и променял слаку на *бунту: хотели быстрых фиксов, даже если они не были достаточно протестированы и добавляют больше проблем чем решают).

Проблем при обновлении обычно нет, но надо учитывать, что без отслеживания зависимостей, можно поставить новый пакет, а что-то от чего он зависит - не поставить. Также надо быть поосторожнее с обновлением ядра, но при использовании slackpkg это не проблема - он сам предлагает переустановить lilo. После обновления пакетов содержащих конфигурационные файлы предлагается решить что с ними делать. Можно решать за все сразу или в индивидуальном порядке. Действия: оставить старый, использовать новый, пропустить, diff, merge.

Все сторонние менеджеры пакетов - оболочки над родной системой пакетов, поэтому установив пакет, дальше с ним можно работать как с родным. В том числе и обновлять.

Аналог AUR вроде бы отсутствует, надо самому выкачивать исходники и делать пакет. Создание пакета настолько простое, что можно обойтись и без специальных утилит.

Если хочется дебиана, используй slapt-get!

Я использую slapt-get и sbopkg. Первый — apt-подобная надстройка над встроенными утилитами. Второй — автоматизирует работу со слакбилдами.

Кстати, полное обновление системы тоже можно делать через slapt-get

Про частоту обновлений

Никаких автоматических обновлений нет. Системные утилиты на стабильных релизах вообще не обновляются, только на current. Из-за этого могут возникать проблемы совместимости нового софта со старыми либами, то есть, если хочешь новый софт — используй current, и обновляйся раз в 3-4 месяца.

Аналога аура нет, и не нужно, чтобы всякие там .. :-) совали что не попадя. Есть http://slackbuilds.org/ где под чутким и строгим контролем можно размещать свои слакбилды, ну и естесвенно, брать чужие.

SlackBuilds это конечно да. Я не осведомлён насчёт правил размещения пакетов в AUR и отметил это только в плане той разницы, что системы контроля версий надо использовать самому, SlackBuilds только из архивов с исходниками собирает (хотя если надо, не составит особого труда и из snapshot пакет собрать).

Отдельных security обновлений нету. «Просто чтобы было» в слаке пакет никто не обновит (я говорю об официальных пакетах).

Феерический бред.
При обнаружении проблем с безопасностью выпускаются патчи. Уведомление записывается в /ChangeLog.txt в репозитории, собранные пакеты укладываются в /patches/packages, исходники — в /patches/source, сообщение размещается на офсайте http://slackware.com/security/ и в рассылке slackware-security.
Для автоматизации обновления подходит slackpkg (руководство http://www.slackpkg.org/documentation.html) в частности,
slackpkg check-updates — проверка факта наличия обновлений
slackpkg update — обновление описаний пакетов
slackpkg upgrade-all — обновление обновленных пакетов

процедура обновления Slackware

slackpkg install-new
slackpkg upgrade-all
slackpkg clean-distro
reboot

Спасибо, такого ответа и ждал.

Спасибо. Значит надо будет подписываться на slackware-security.

генерируем новый список зеркал для slackpkg
slackpkg new-config

Это совершенно о другом. В состав пакетов файлы конфигурации включаются с добавлением в хвост имени .new. Делается это, чтобы конфиг из пакета не затирал существующие настройки. При установке пакета .new конфиг сверяется с существующим, и, если идентичен, удаляется. В результате остаются только те, что отличаются. При ручном обновлении (wget+upgradepkg) задача объединения мейнстримных изменений (зачастую существенных и необходимых) с собственными конфигами лежит на админе.
slackpkg new-config ищет ниже /etc файлы по маске *.new и предлагает смежить их с оригинальными.
При обновлении с помощью slackpkg upgrade-all указанная фаза запускается по завершении обновлений автоматически. Но если по каким-то причинам что-то было отложено на потом, можно позвать slackpkg new-config вручную.

мой косяк :-)

В этом плане пакбилды лучше слакбилдов, так как позволяют собирать и из различных svn etc. Но политика партии и правительства такова, что стабильность превыше всего, и если собранный слакбилдом пакет всегда можно проверить на стабильность и совместимость, то собранное из svn пакет проверить таким образом изначально нельзя

Феерический бред.

Согласен :-). Спасибо за попраку. Я совсем забыл про те патчи, наверное, потому что применял их только пару раз. И так как я не админ, то мне не критично.

процедура обновления Slackware
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-distro
reboot

Отлично.
Отлично от правильного.

Нужно отличать установку обновлений безопасности и апгрейд системы до новой версии (или current).

После выпуска конкретной версии, скажем Slackware-13.37, могут быть только обновления безопасности, как правило, изменяется номер сборки пакета/тэг, все они попадают в /patches, никакого нового ПО в релиз не добавляется. Поэтому slackpkg install-new бесполезен, ведь он предлагает к установке только то, что в ChangeLog.txt помечено как Added и нужен только для апгрейда на новый выпуск дистрибутива.
slackpkg clean-system нужен тоже только при переезде на новый выпуск, поскольку предлагает к удалению пакеты, отсутствующие в пакетной базе конкретного выпуска, а потому с точки зрения установки обновлений безопасности бесполезен и даже вреден (можно поудалять поставленное самостоятельно).
Перед slackpkg upgrade-all необходим slackpkg update, он заберет с зеркала ChangeLog.txt и описания пакетов, без него не будет сведений об обновленных пакетах.

http://mirror.yandex.ru/slackware/slackware-14.0/UPGRADE.TXT

постоянно обновляетесь с зеркала Яндекса? Не замечали за ним случаев неполного зеркала? Просто когда-то я тоже его использовал, но несмотря на скорость и локальный трафик с него вынужден был отказаться из-за сбоев в зеркале. Как оно сейчас?

А секьюрити фиксы?

В этом плане пакбилды лучше слакбилдов, так как позволяют собирать и из различных svn etc.

Слабилд — это обыкновенный сценарий оболочки, который может все.

Но политика партии и правительства такова, что стабильность превыше всего, и если собранный слакбилдом пакет всегда можно проверить на стабильность и совместимость, то собранное из svn пакет проверить таким образом изначально нельзя

Любая VCS позволяет ссылаться на конкретную ревизию, это одна из базовых функций (man cvs, man svn, man hg, man git, ...) так что вывод про «проверить нельзя» надуманный.
Требование файла .info со ссылкой только на тарбол с исходниками — исключительная придумка slackbuilds.org, не более того. Например, сценарии со slacky.eu традиционно содержат ссылку на исходники и код загрузки внутри себя, подобным же образом собирает AlienBOB, например, http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/ffmpeg/...
http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/bui...
Поэтому делать всеобщие выводы на основе не самого удачного решения одного, хотя и достаточно популярного, сборника слакбилдов я бы не стал. Потому и с вашими категорически не согласен.

ps. Сколько же мифов вокруг этого дистрибутива...

Пока морально готовлюсь - читаю HOWTO и слакбук.

Тогда вдогонку, помимо официального форума поддержки:
http://www.linuxquestions.org/questions/slackware-14/
свежеорганизованный источник информации по Slackware:
http://docs.slackware.com
попытка объединить разрозненные знания в одном месте.

Естественно может все, но для собственного применения. для которого и сам по себе слакбилд не так уж и не нужен.
Мм, аргументация в части стабильности. кстати, не моя, а rworkman. Когда его в рассылке спросили, почему принимают только тарбаллы, ответ был простой и вообще то понятный «svn это помойка автора, из которой он по мере готовности релизит прогу тарбаллом, и только автор может знать когда его прога готова к релизу»
И потом, куда прикажете отсылать слакбилд ? На slacky.eu я хотел, но так и не смог отослать салкбилд именно с svn По сути сейчас только slackbuilds.org место, куда можно без проблем отослать свой склабилд для пользования его чужими. Для своего же пользования слакбилд вообще то не нужен.
Естественно авторы с именами, типа инопланетянина, содержат свои хранилища, где пишут слакблды как хотят, но инопланетян чего на шарике маловато :-)

Пару слов про Slackware и зависимости.
Для знакомства с дистрибутивом настоятельно рекомендуется full install нужных серий. За исключением KDEI — локализаций KDE — рекомендуется уже после установки доставить из нее пару пакетов с нужным(и) языком, ведь наверняка все локализации кде не нужны, а места они занимают много. Поэтому серия KDEI изначально не отмечена для установки.
Не нужен KDE — не ставьте серию KDE. Аналогично и с другими, кроме A, AP, L, N, X, XAP. Но наверняка захочется что-то собрать со стороны, те же проприетарные драйверы, без серий D и К не обойтись, и т.д.
В таком варианте неразрешенных зависимостей нет, проблема отсутствует.
Попытки прикручивания автоматического разрешения зависимостей есть, есть среди них весьма успешные, если не считать принятую в Slackware особенность пакетирования — один проект — один пакет (не плодить количество пакетов без меры). Про результат писал ранее:
http://forum.posix.ru/viewtopic.php?pid=36590#p36590
http://linuxforum.ru/viewtopic.php?pid=192940#p192940

Спасибо за советы.

> постоянно обновляетесь с зеркала Яндекса?

почти.

> Не замечали за ним случаев неполного зеркала?

нет, но иногда замечал сильное проседание скорости, да и не очень оперативно зеркалят, бывало с суточным опозданием. последнее не критично, разве что жду апдейта лисицы или секюритификсов. вот в таких случаях временно перехожу на другое зеркало.

Слака бывает двух сортов: релиз и карент. Для релиза выходят только обновления безопасности, для карента — обновление всго, что впрочем само по себе может быть не безопасно. На тему обновлений безопасности есть рассылка (security@slackware.com). Обновления безопасности лучше не игнорировать.

Помимо прочего есть ресурс SlackBuilds.org выполняющий роль чего-то вроде AURа и тулза sbopkg позволяющая с ним легко работать. Многие вещи, которых нет в дистрибутиве доступны там.

Свои пакеты собираешь и поддерживаешь сам. Главное не забывать собирать пакеты. А ещё лучше писать слакбилды (потом будет проще обновляться). Если ты зачем-то пересобрал часть базовой системы (например ядро) то её лучше всего внести в блеклист slackpkg чтобы потом случайно не обновить её из репозитроия.

По моему всё. Ещё вопросы?

самый полный ответ. единственное что раздражает - это вопросы по поводу каждого изменившегося конфига - что с ним делать.

раздражает - это вопросы по поводу каждого изменившегося конфига - что с ним делать

# slackpkg new-config

Searching for NEW configuration files

Some packages had new configuration files installed.
You have four choices:

	(K)eep the old files and consider .new files later

	(O)verwrite all old files with the new ones. The
	   old files will be stored with the suffix .orig

	(R)emove all .new files

	(P)rompt K, O, R selection for every single file
	
What do you want (K/O/R/P)?

K/O/R относятся ко ВСЕМ .new файлам, можете рискнуть ;-)

зная слаку, я всегда делаю R

всегда делаю R

Если речь о переходе с выпуска на выпуск, то просто безрассудство (в новых версиях бывают новые настройки).
Если речь об обновлениях безопасности, то иногда единственным изменением может быть новая/изменённая опция файла конфигурации — обновление пройдёт даром.

я всегда делаю R

Чуть не забыл, в rc.d сценарии (и их обновления) тоже приходят с суффиксом .new:

grep -R /rc\.d/.*\.new$ /var/log/packages|wc -l
47