forum.lissyara.su

Добавлено: **2008-02-10 19:56:30**

ставлю фрю 6.2, там xorg 6 версии при обновлении портов через portupgrade вылазит сообщение

/usr/X11R6 exists, but it is not a symlink. Installation cannot proceed.
This looks like an incompletely removed old version of X.  In the current version, /usr/X11R6 must be a symlink if it exists at all.Please read /usr/ports/UPDATING (entry of 20070519) for the procedure to upgrade X.org related ports.*** Error code 1

это пол-беды, иду в /usr/ports/UPDATING там есть строчки

Код: Выделить всё

  Unfortunately portupgrade (nor portupgrade-devel) cannot yet handle
  the rigors of the xorg upgrade without a small bit of help:

  # portupgrade -Rf libXft

  If your machine does NOT have any gstreamer ports installed, you can then
  run:

  # portupgrade -a

  However, if you DO have gstreamer ports installed, you must run:

  # portupgrade -a -x 'gstreamer*'

  Followed by:

  # portupgrade -Rr 'gstreamer*'

  When packages are available (wait for the announcement on ports@), you
  may prefer to use precompiled packages to speed up the process:

  # portupgrade -aP

  Once the upgrade completes successfully, you can delete the
  xorg-manpages package, which is now orphaned.

  # pkg_delete xorg-manpages\*

  The final step is to merge remaining files from /usr/X11R6 into
  /usr/local (/usr/X11R6 is no longer used with xorg 7.2) and replace
  /usr/X11R6 with a symlink.

мне не понятно следующее:
1. кто такой gstreamer и зачем он нужен?
2. как откатить обновления если какая-то библиотека не захотела обновлятся или я прервал обновление?
3. как откатить все обновления?

Добавлено: **2008-02-10 20:13:41**

В дереве портов давно уже Xorg 7.3 (с октября 2007, если не вру). Так что лучше обновить систему до 6.3-RELEASE и локальную копию портов и не заморачиваться переходом с Xorg 6.9 на 7.2.

Добавлено: **2008-02-10 20:20:40**

а как обновить до 6.3?

делал по статье http://www.lissyara.su/?id=1161 обновилась до FreeBSD 6.2-RELEASE-p10 #2

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

Добавлено: **2008-02-10 23:01:06**

в stable-supfile надо привести строчку к такому виду

Код: Выделить всё

default release=cvs tag RELENG_6

и потом по статье

Код: Выделить всё

cvsup /path/stable-supfile

.
У меня все ок. 2 сервака ща обновляю....

Код: Выделить всё

P.S. Привет всем! Я вернулся  :P

Добавлено: **2008-02-11 0:44:26**

alex3 писал(а):в stable-supfile надо привести строчку к такому виду
Код: Выделить всё
default release=cvs tag RELENG_6

Строчка неправильная!
6.3-RELEASE имеет код RELENG_6_3.

alex3 писал(а): и потом по статье
Код: Выделить всё
cvsup /path/stable-supfile
.
У меня все ок. 2 сервака ща обновляю....

Вместо cvsup лучше использовать встроенную системную утилиту csup.

Добавлено: **2008-02-11 0:48:52**

Конфиг /etc/sys-supfile:

Код: Выделить всё

*default host=cvsup7.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs
*default tag=RELENG_6_3
*default delete use-rel-suffix
*default compress
src-all

Обновление:

Код: Выделить всё

% csup /etc/sys-supfile

Команды по пересборке системы:

Код: Выделить всё

% cd /usr/obj && chflags -R noschg *
% cd /usr/obj && rm -rf *
% cd /usr/src && make cleandir && make cleandir && make cleandir
% cd /sys/i386/conf && cp GENERIC OTHERGENERIC
% ee /sys/i386/conf/OTHERGENERIC #<--тут отредактировал конфиг ядра
% ee /etc/make.conf #<--тут отредактировал конфиг make
% cd /usr/src && make -j2 buildworld
% cd /usr/src && make buildkernel KERNCONF=OTHERGENERIC
% cd /usr/src && make installkernel KERNCONF=OTHERGENERIC
% reboot
% ps
% top #<--тут проверил работоспособность нового ядра
^C
% shutdown now
% cd /usr/src && make installworld
% mergemaster #<--обновил конфиги
% reboot

Добавлено: **2008-02-11 1:20:38**

iZEN писал(а): Обновление:
Код: Выделить всё
% csup /etc/sys-supfile

не приучайте людей к линуксовой порнографии - /etc - место для системных настроек, но, никак не для csup

Добавлено: **2008-02-11 1:36:38**

lissyara писал(а):
iZEN писал(а): Обновление:
Код: Выделить всё
% csup /etc/sys-supfile
не приучайте людей к линуксовой порнографии - /etc - место для системных настроек, но, никак не для csup

Оффтоп
Порнография -- это когда приложение растекается своими файлами по древу /usr/local/ и подкаталогам, а не хранит свою структуру в отдельном подкаталоге /usr/local/prilojenie, откуда его можно в случае поломки базы портов вручную "выцепить". Так нет же -- знакомый с децтва DLL-hell (ой, простите, .so-hell) разруливается причудливыми перемещениями/переименованиями/ссылками неудобных библиотек, лежащих в одной куче, с помощью системы портов!

Так где мне хранить конфиг, если полсистемы слетит с разделом /usr/local?

Добавлено: **2008-02-11 7:59:48**

Вы серьёзную систему строите, или в детский сад играете?
Если первое - у вас есть бэкап, если второе - извините, развлекайтесь как хотите.
==========
что касается "поломки базы портов" - это как?
У меня однажды слетело всё содержимое той самой базы, остались пустые директории.
Просто пересобрал весь софт.
Было это на сервере, софта не много, машина быстрая - пару часов...

Добавлено: **2008-02-11 10:41:41**

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

обновлял wine через portupgare, заткнулось на xorg'е.. собрал из обновлённых портов - собралось, правда не заработала; там и там вине-0.9.55. Люди скажите, чем отличается portupgrade от cvsup и портов?

Добавлено: **2008-02-11 10:44:06**

портупграде - это просто аппликуха которая грамотно и с зависимостями обновляет приложение из портов
Всё это ты можешь делать и руками - но ей удобней

Добавлено: **2008-02-11 13:53:13**

ясно, буду пробовать, спасибо

Добавлено: **2008-02-11 16:21:03**

iZEN писал(а):Оффтоп
Порнография -- это когда приложение растекается своими файлами по древу /usr/local/ и подкаталогам, а не хранит свою структуру в отдельном подкаталоге /usr/local/prilojenie, откуда его можно в случае поломки базы портов вручную "выцепить". Так нет же -- знакомый с децтва DLL-hell (ой, простите, .so-hell) разруливается причудливыми перемещениями/переименованиями/ссылками неудобных библиотек, лежащих в одной куче, с помощью системы портов!

Так где мне хранить конфиг, если полсистемы слетит с разделом /usr/local?

тока что сообразил - это у меня дома 600 приложений стоит, в будет /usr/loca/<600_субдиректорий>/

и в переменной с путями не прописывать по меньшей мере 1200 путей?
И при компиляции, например kdabase/kdelibs - у каждого из которых по нескольку сот зависмостей - к каждой из них указывать путь отдельным ключиком?
===========
и именно сейчас я понял почему так не делают.
и линукосиды ещё больше уменьшили это всё смешав в кучу систему и приложения...
Впрочем... Система у них ядро - и только, такчто модель с этой точки зрения - верная.

Добавлено: **2008-02-11 18:26:04**

lissyara писал(а):тока что сообразил - это у меня дома 600 приложений стоит, в будет /usr/loca/<600_субдиректорий>/
и в переменной с путями не прописывать по меньшей мере 1200 путей?
И при компиляции, например kdabase/kdelibs - у каждого из которых по нескольку сот зависмостей - к каждой из них указывать путь отдельным ключиком?
===========
и именно сейчас я понял почему так не делают.
и линукосиды ещё больше уменьшили это всё смешав в кучу систему и приложения...
Впрочем... Система у них ядро - и только, такчто модель с этой точки зрения - верная.

Когда приложения будут иметь собственные каталоги, то они не должны иметь между собой зависимостей, следовательно, прописывать пути ко всем библиотекам от всех приложений не надо. Каждое приложение будет иметь независимый стэк библиотек в собственном каталоге, и они не будут зависеть или от них не будут зависеть библиотеки других приложний. В этом случае менеджмент прикладного ПО сильно упроститься, но потребуется в полтора-два максимум в три раза больше места на диске в том числе за счёт дублирующихся библиотек.

Дальнейшая популяризация UNIX как настольной системы приведёт к потоку коммерческих решений. Это будет способствовать привнесению в систему различных "общих" библиотек, в том числе с внедрённым Ad-Ware кодом рекламного характера. При существющем механизме обобществления библиотек и сваливания их в одну кучу, когда несколько десятков приложений используют одну и ту же библиотеку, это может привести к наплыву спама.
Локализация бибиотеки в каталоге установленного приложения позволяет точнее определить источник Ad-Ware и избавиться от него, вообще не затрагивая другие приложения — работа других приложений не нарушается.
Таким образом, ради безопасности лучше идти к изолированным агрегатам библиотек, чем использовать общее библиотечное пространство для всех приложений.

Добавлено: **2008-02-12 1:39:51**

iZEN писал(а):Когда приложения будут иметь собственные каталоги, то они не должны иметь между собой зависимостей, следовательно, прописывать пути ко всем библиотекам от всех приложений не надо.

нет. вот есть у меня утилита колризе. гимп. опера. птица. лиса...
каждый в совей дире. внутри диры бин и там аппликуха.
чтобы я с ЛЮБОГО места файловой системы мог набрать команду и она выполнилась она должна быть в путях.
итого - в переменной PATH у меня 600 путей.
логику уловил?

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

клёво... однако, порубаю идею находу:

Код: Выделить всё

pkg_info -R gettext-0.16.1_3 | wc -l
     224

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

)) и все по разным путям

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

iZEN писал(а): Дальнейшая популяризация UNIX как настольной системы приведёт к потоку коммерческих решений. Это будет способствовать привнесению в систему различных "общих" библиотек, в том числе с внедрённым Ad-Ware кодом рекламного характера. При существющем механизме обобществления библиотек и сваливания их в одну кучу, когда несколько десятков приложений используют одну и ту же библиотеку, это может привести к наплыву спама.

а это решение пользователя - что ставить а что нет.
не надо это у него отбирать - иначе в винду превратимся

iZEN писал(а): Локализация бибиотеки в каталоге установленного приложения позволяет точнее определить источник Ad-Ware и избавиться от него, вообще не затрагивая другие приложения — работа других приложений не нарушается.

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

iZEN писал(а): Таким образом, ради безопасности лучше идти к изолированным агрегатам библиотек, чем использовать общее библиотечное пространство для всех приложений.

точно. весь мир идёт неправильно, ты один знаешь верный путь.
пиши в рассылку фрибсд - обсуди идею с разработчиками.
===========
ну а серьёзно - ты просто неправ.

Добавлено: **2008-02-12 11:29:04**

lissyara писал(а):
iZEN писал(а):Когда приложения будут иметь собственные каталоги, то они не должны иметь между собой зависимостей, следовательно, прописывать пути ко всем библиотекам от всех приложений не надо.
нет. вот есть у меня утилита колризе. гимп. опера. птица. лиса...
каждый в совей дире. внутри диры бин и там аппликуха.
чтобы я с ЛЮБОГО места файловой системы мог набрать команду и она выполнилась она должна быть в путях.
итого - в переменной PATH у меня 600 путей.
логику уловил?

Несовсем.
Я так не утрирую донельзя.
Есть каталог /usr/local/bin, вот там могут находится все ссылки на все приложения, установленные в системе. И путь для запуска будет один: $PATH=/usr/local/bin, графические оболочки могут использовать этот каталог для динамической настройки своих Главных меню и командных оболочек.

lissyara писал(а):
iZEN писал(а):Каждое приложение будет иметь независимый стэк библиотек в собственном каталоге, и они не будут зависеть или от них не будут зависеть библиотеки других приложний. В этом случае менеджмент прикладного ПО сильно упроститься, но потребуется в полтора-два максимум в три раза больше места на диске в том числе за счёт дублирующихся библиотек.
клёво... однако, порубаю идею находу:
Код: Выделить всё
pkg_info -R gettext-0.16.1_3 | wc -l
     224
пояснить? это значит что при твоём подходе у меня в системе будет 224 геттекста...
прикинь каково мне их обновлять если баг найдут? )) и все по разным путям
и с местом нестыковка. думаю, раз в 10-20 больше уёдт. т.е. вместо моих двух гиг софта будет 20...
и в памяти придётся держать в 10 раз больше.
значит вместо нынешнего гектара рамы мне надо именть 10 на машине...

Значит нужно придумать механизм агрегации общего рантайма и отделить его от приложений чётко оформленным интерфейсом, как это сделано в Java Runtime Environment, а не плодить кучу несовместимых gettext, из-за которых иногда случается невозможность собрать тот или иной порт — было у меня меньше года назад, когда pkgdb не спасала.

Добавлено: **2008-02-12 13:35:26**

iZEN писал(а):Несовсем.
Я так не утрирую донельзя.
Есть каталог /usr/local/bin, вот там могут находится все ссылки на все приложения, установленные в системе. И путь для запуска будет один: $PATH=/usr/local/bin, графические оболочки могут использовать этот каталог для динамической настройки своих Главных меню и командных оболочек

от ты трудный...
т.е. всё симлинками предлагаешь сделать?
Приложения из портов на моей машине наинсталлили пару десятков тысяч файлов.
плюс стока же симлинков - изврат.
и не забываем, что в /usr/local уже 600 директорий, в каждой из которых продублирована - полностью или нет структура вида bin, sbin, share, man ....
вот просто изврат... ещё же есть не тока бинарники - всякие маны-шары-либы...

iZEN писал(а):Значит нужно придумать механизм агрегации общего рантайма и отделить его от приложений чётко оформленным интерфейсом, как это сделано в Java Runtime Environment, а не плодить кучу несовместимых gettext, из-за которых иногда случается невозможность собрать тот или иной порт — было у меня меньше года назад, когда pkgdb не спасала.

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

Добавлено: **2008-02-12 13:49:28**

тут дело в кривизне алиасов

Есть каталог /usr/local/bin, вот там могут находится все ссылки на все приложения, установленные в системе. И путь для запуска будет один: $PATH=/usr/local/bin

полное гонево

man env

lissyara

Его подход- прямая дорога к cross-symlink bof

Добавлено: **2008-02-18 1:21:46**

помогите установить xorg.. а то без иксов не хочет..... как его заставить поставиться?? в портах уже 7.2

Добавлено: **2008-02-18 2:02:31**

хто здеся?

Добавлено: **2008-02-18 3:54:58**

в смысле?? ...
мне при попытке либы установить выдает такое же сообщение, как и в начале топика... куда копать?

Добавлено: **2008-02-18 8:36:17**

если хоцца копать, то в /usr/ports/UPDATING, если желания нет, то ставь семёрку и обновляй её

а вообще как я понял каталог /usr/X11R6 упразднили, поэтому требуется чтоб это был не каталог а символическая ссылка на /usr/local, типа это круче. Единственное но - когда я попытался сделать как написаано в /usr/ports/UPDATING своими корявками запорол напрочь все X'ы, пришлось фрю переставлять

Хотя конечно тоже экспа

Добавлено: **2008-02-18 12:38:48**

на той неделе делал.
всё прокатило кроме скрипта про мергебазе - пришлось тупо снести /usr/X11R6 и сделать симлинк

Добавлено: **2008-02-19 0:28:26**

а как конкретно это сделать? подкажи по шагам...

Добавлено: **2008-02-19 0:45:12**

как написано в упдатинг

forum.lissyara.su

обновление xorg-6.9 => 7.2

обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2

Re: обновление xorg-6.9 => 7.2