Easy To Manage Linux (ETML)

Забыл сказать, скриншот мой.

Долко гемороился?

Не очень понял проблему обновления glibc? Чего там трудного? Сборка исходников проходит на старых глибсях, а при установке просто переписываются старые библиотеки новыми с помощью простого install (все равно что cp+chmod+strip) и чего лепить дополнительно каталоги мне не ясно. Если ты боишься что у тебя при стирании библиотеки полетит система то ты ошибаешься - почитай про устройство файловых систем линукса - и поймешь, что если одна программа юзает файл - он не будет стерт пока она с ним работает, даже если ты из файловой таблицы сотрешь его имя - проге на жто будет плевать, потому что она работает не с именем а с НОМЕРОМ файла, который может стереть только ядро. Поэтому нередки ситуации что при установке новых глибсей и стирании старых, те программы которые были запущены до апдейта - работают со старой версией библиотек, а те которые запущены после - уже с новыми. Кстати на основе именно этого свойства большинство юниксов избавлено от необходимости перезагрузки после каждого апдейта даже критичных библиотек.

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

2xah7ep (*) (2002-10-14 11:38:41.957):
Нет не долго. Темболее у меня небыло "цели" сделать именно так, все происходило постепенно.

2oduvan (*) (2002-10-14 12:02:18.551):
Итак, пердположим что у тебя cp/ls/mv/и все остальное прилинкованно _динамически_ (споры о том что нужно делать их статическими, думаю можно оставить на другой тред). Теперь удаляй /lib/ld.so.2 или /lib/libc.so.6 и наслаждайся нерабочей системой. ;-)
Ты просто перепутал, если программа _уже_ сидит в памяти, то да, хоть удаляй, хоть нет программа будет продолжать работать, но ново-загруженные программки работать _не будут_.

"Поэтому нередки ситуации что при установке новых глибсей и стирании старых"

Вот вот. "стирании старых", ты будешь каждый файл искать от старых либ.
Ведь обновление либы происходить в два этапа
rm /lib/ld.so.2
#теперь уже динамического линкера _нету_
cp /home/<login>/obj/elf/ld.so.2 /lib/ld.so.2 # это команда выдаст что не может найти ld.so.2. Выход есть, делать это с помощью
$ /home/<login>/obj/elf/ld.so.2 cp /home/<log....... (т.е. загружать программку через динамический линкер напрямую), но так glibc не делает, и предупреждает в FAQ, чтобы _не инсталили_ новую glibc туда, где стояла старая. RTFM ;-)

Потом не нужно забывать, что эта системка _удобна_. glibc я взял для примера.

Да и еще, забыл совсем. Идея это не моя, нужно отдать должное linux-kernel, который делает точно также. Вспомним:
/usr/src/linux это есть ссылка на /usr/src/linux-<версия>, а /usr/include/linux это есть ссылка на /usr/src/linux/include (которая тоже ссылка).
Вобщем способ не нов и очень эффективен.

> а /usr/include/linux это есть ссылка на /usr/src/linux/include (которая тоже ссылка).

Да ? А сам Линус совсем другое писал по поводу "шита симлинков", читай LFS.

4anonymous (*) (2002-10-14 12:28:35.715):
Никто не мешает каждому иметь свое ИМХО.
Я гденибуть говорил про Линуса? Я говорил, что almost all дистрибутивы используют так ядро. И в описании установки ядра тоже говорится про симлинкование. Чтобы там линус не говорил, но оно так уже есть.
LFS у меня есть, скажи страницу где там это говорится.

Чайник, glibc ставится в single mode! Компилишь, грузишся в "linux S" и make install. Документацию тут написал блин... RTFM!

loGIN: всё хорошо, только выпендриваться много не нужно, родной. страница 74 LFS (4rc1).

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

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

2. конфигурационные файлы. их приходится хранить отдельно в "живом" виде. причём с ними нужно как-то управиться при добавлении/удалении пакета: не допустить затирания старых новыми и обеспечить корректное изменение при сносе пакета. что делать с конфигурационными файлами в старых форматах, которые возможно не поддерживаются новой версией ПО?

3. изменяемые данные пакета. как быть с ними? например, по ходу работы я добавляю много latex-макросов в /usr/share/texmf/. при смене версии пакета (изменении линка) -- эти данные пропадут. нет, не нужно говорить мне что тех -- одно большое глюкало. я его использую и он мне нужен, хотя, конечно, не устраивает своим выпаданием из концепции.

трёх, наверное достаточно, чтобы откатиться обратно на rpm/deb/что-то_ещё_там. мне лично нравится простота.

"Чайник, glibc ставится в single mode! Компилишь, грузишся в "linux S" и make install. Документацию тут написал блин... RTFM!"

См. выше. С этой системой _не нужно_ ничего ребутить. Все остальные преемущества описаны выше.
Предположим сегодня сказали, что в splain(перловская штука) есть баг, который может быть использован в DoS. Ты будешь судорожно искать откуда эта фича взялась? Тебе повезет если рпм скажет, а если нету рпм? ;-)

--

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

см. выше у меня есть тривиальная программка, которая отследит за этим. Какие symlink'и стали бесполезными, а какие нужно добавить. Ведь структура /usr/packs/<пакет>/ ровно такая же как и "/". Просто нужно зеркально отобразить /usr/packs/<pack> в "/". Обо всем этом я уже не задумываюсь, за меня это делает ETML. ;-)

--
"2. конфигурационные файлы. их приходится хранить отдельно в "живом" виде. причём с ними нужно как-то управиться при добавлении/удалении пакета: не допустить затирания старых новыми и обеспечить корректное изменение при сносе пакета. что делать с конфигурационными файлами в старых форматах, которые возможно не поддерживаются новой версией ПО?"

Ни один пакет _НЕ ИМЕЕТ ПРАВА_ что-либо удалять или изменять в /etc, исключительно добавлять. Тем более ни один пакетный менеджер _НЕ ИМЕЕТ ПРАВА_ удалять якобы "не нужные/устаревшие/больше не используемые файлы" из /etc. Это абсурд. Откуда пакет/пакетный мэнеджер знает, что этот файл _Вам_ больше не нужен?
А на счет управления с .conf файлами, то это делает опять же та самая программка.
Может быть выложу ее куданибуть, но я сильно сомневаюсь, что есть еще такие извращенцы как я. А если и есть, то они уже сами себе сделали. ;-))

--
"3. изменяемые данные пакета. как быть с ними? например, по ходу работы я добавляю много latex-макросов в /usr/share/texmf/. при смене версии пакета (изменении линка) -- эти данные пропадут."

/usr/share принадлежит root'y. Какое право Вы имеете изменять содержимое пакета? Тем самым вы добавляете "что-либо" к стандарту (оригинальному пакету), а значит если при следующей установке пакета "что-либо" пропало - это ваши проблемы. Свои наработки/макросы нужно хранить у себя в домашнем каталоге. Это - unix policy.
Причем многие пакеты делают инсталляцию грубо - rm <prefix>; mkdir <prefix>; cp.... Сохранность файлов тебе гарантируют только в /etc и в твоем домашнем каталоге.

--
"не нужно говорить мне что тех -- одно большое глюкало."
И не буду, очень хорошая штука. ;-)

--
"трёх, наверное достаточно, чтобы откатиться обратно на rpm/deb/что-то_ещё_там. мне лично нравится простота."

О Чем я и говорю. куда проще ./configure --prefix=/usr/packs/<pack> && make && make install && etml-update-packs ;-)

ИМХО это подходит для тех, кто действительно не переносит на дух RPM/deb, но хочет следить за пакетами.

--
p.s. я почему то думал, что на этот скрин ответит ifconfig, заядлый LFS-ник. Может он оценит? ;-))

2jc (*) (2002-10-14 16:01:36.453):
Прочел страницу 74. Линус, конечно, прав относительно того, что хидеры ядра могут повлият на object файлы, которые в свою очередь будут иметь проблемы с glibc.
Однако старые "деды" линукса ИМХО до сих пор симлинкуют. см. Slackware 7.1. Другой версии слаки у меня нету под рукой.

И всеравно, на общую идею etml это не влияет, по понятным причинам (sh-utils (и все остальное) != ядро).

Причем если посмотреть в FAQ glibc/gcc, то там сказанно в какой последовательности нужно пересобирать систему.
0. kernel - этого не сказанно, но это и ежу ясно
1. binutils
2. glibc
3. gcc
Если поменял kernel, то _самое лучшее_ перекомпилить 1.binutils, 2.glibc, 3.gcc. В этом случае проблеммы с симлинковаными хидерами не возникает.
А если поменял ядро, но не удасужился поменять binutils, glibc, gcc - негативный результат может проявиться в тот или иной момент.
Хотя, лично я, на десктопе никогда так не делаю. Проблема появится - исправлю. ;-)

2logIN: в последней версии слаки убрали симлинк :), так что другой пример.
Спектратор.

Народ! А никто не задумывался что слуись что; /usr/ не будет примонтирован и ... привет! в /bin ссылки на /usr/<где то там> Пи$dец системе ;)

Уважаемый logIN,

Чтобы не оказаться без библиотек после удаления старой и до копирования новой - пишите одной командой и удаление и копирование:

rm /lib/ld.so.2; cp /home/<login>/obj/elf/ld.so.2 /lib/ld.so.2

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

... хотел сказать вот так:

# rm /lib/ld.so.2; cp /home/<login>/obj/elf/ld.so.2 /lib/ld.so.2

... так лучше

2anonymous (*) (2002-10-14 19:48:57.199):
Так создай /packs а не /usr/packs, кто мешает??
Фантазия у Вас отсутствует. ;-)
В моем конкретном случае /usr/packs работает потому, что / и /usr принадлежат одному партишну.

"Чтобы не оказаться без библиотек после удаления старой и до копирования новой - пишите одной командой и удаление и копирование:
rm /lib/ld.so.2; cp /home/<login>/obj/elf/ld.so.2 /lib/ld.so.2"

Команды будут выполняться одна за другой. Сначала удалит ld.so.2, а cp уже не загрузится. Не катит. Чтобы так сработало, rm и cp должны уже быть в памяти (т.е. пока они в памяти они _уже_ прилинкованы).

--
Короче, чего вы прислали к glibc? ;-))
Ведь это удобно для многих других пакетов. Можно держать кучу разных версий и откатываться на нужную с помощью двух команд.

-прислали+пристали ;-)

logIN,

А вы попробуйте :)

Команды выполнятся _одним шелом_, и в процессе (между удалением и копированием) занятая библиотека отобрана и него (у шела) не будет. Об этом справедливо один товарищ выше писал...

Да и не только к глибу это относится. Это вполне обычный прием. Давно его вычитал на библиотеке Мошкова и с тех пор пользуюсь. Способ проверенный :)

Хм... Ну действительно - только для копирования глиб такой огород городить незачем.

А вот версии так держать - конечно смысл есть. Не уверен что версии ls надо держать, но вот такое наверняка удобно:

jdk_1.3.1 jdk_1.2 jdk -> jdk_1.3.1

- ну что-то в этом роде... Практически то же что вы описали.

Мне нравится! Боюсь правда, что для меня (anonymous'а) это будет слишком сложно.

2anonymous (*) (2002-10-14 21:09:31.535):
Ок, поверю на слова. Хотя удивительно. Ладно, всеравно не в этом суть. ;-))
Проблема glibc имеет множество решений.

Я бо'льший акцент делал на удобство.

2"Команды выполнятся _одним шелом_, и в процессе (между удалением и копированием) занятая библиотека отобрана и него (у шела) не будет. Об этом справедливо один товарищ выше писал..."

Я тут вчитался, подумал. А причем тут шелл? mv/cp/rm слинкованы динамически. Загружаться команды будут всеравно по порядку.
Если шелл _уже_ загружен, то есстественно он будет работать даже без либы. Другое дело cp/mv, они _еще_ не загружены, а либы _уже_ нету (_уже_ нету после rm).
Не катит.

Очень просто...

Когда вы запускаете одну команду:

rm ...

а потом другую:

cp ...

- тогда произойдет следующее - запустится один процесс, займет глиб, удалит его, а потом и завершится сам. После чего второй процесс не найдет глиб...

А если написать:

# rm ...; cp ...

- то очевидно что запустится один процесс, который займет глиб, потом удалит его (при этом его занятая копия останется при нем), выполнит копирование, и завершится...

Хоть rm и cp и будут загружаться последовательно, они получат от своего родителя (одного для обоих) одно окружение. В котором будет динамически загруженная глиб.

А вот если их последовательно запускать - то родители будут разные у rm и у cp. И у второго глиба уже не окажется.

logIN, продолжим?

<< "1. состав пакетов. от версии к версии состав пакетов может изменяться. ... см. выше у меня есть тривиальная программка, которая отследит за этим. Какие symlink'и стали бесполезными, а какие нужно добавить. Ведь структура /usr/packs/<пакет>/ ровно такая же как и "/". Просто нужно зеркально отобразить /usr/packs/<pack> в "/". Обо всем этом я уже не задумываюсь, за меня это делает ETML. ;-) >>

стоп. замена пакетов уже не становится тривиальной сменой линка. нужно ещё вызывать etml-update-packs и ждать. кроме того, нужно помнить после каких пакетов нужно запускать etml-update-packs, а после каких -- нет. кажется этот плюс исчезает.

<< "2. конфигурационные файлы. их приходится хранить отдельно в "живом" ... Ни один пакет _НЕ ИМЕЕТ ПРАВА_ что-либо удалять или изменять в /etc, исключительно добавлять. Тем более ни один пакетный менеджер _НЕ ИМЕЕТ ПРАВА_ удалять якобы "не нужные/устаревшие/больше не используемые файлы" из /etc. Это абсурд. >>

ой, да что ты? правда? а откуда новые юзеры появляются в /etc/passwd при установке демонов (fcron, например) знаешь? прально. их создают пакманагеры по пост-ин скриптам. ну или инстал.ш в скаквейр.

<< Откуда пакет/пакетный мэнеджер знает, что этот файл _Вам_ больше не нужен? >>

не. Мы тут не причём. пакманагер не за Нас отвечает, он знает что нужно пакету. комплекту ПО.

<< А на счет управления с .conf файлами, то это делает опять же та самая программка. Может быть выложу ее куданибуть, но я сильно сомневаюсь, что есть еще такие извращенцы как я. А если и есть, то они уже сами себе сделали. ;-)) >>

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

<< "3. изменяемые данные пакета. как быть с ними? например, по ходу работы я добавляю много latex-макросов в /usr/share/texmf/. при смене версии пакета (изменении линка) -- эти данные пропадут."

/usr/share принадлежит root'y. Какое право Вы имеете изменять содержимое пакета? >>

а Мы эта... Мы рут :)

<< Тем самым вы добавляете "что-либо" к стандарту (оригинальному пакету), а значит если при следующей установке пакета "что-либо" пропало - это ваши проблемы. Свои наработки/макросы нужно хранить у себя в домашнем каталоге. Это - unix policy. >>

остынь. это не изменение оригинального пакета, а расширение его аддонами. в принципе, каждый аддон можно оформить ввиде пакета и ставить его. но вот не задача: поставляются-то они в виде тривиальных архивов, которые предлагается просто скопировать внутрь теха, а после вызвать несколько команд для реконфигурации. кстати. файлы конфигурации сидят там же, внутри /usr/share/texmf. ку?

<< Причем многие пакеты делают инсталляцию грубо - rm <prefix>; mkdir <prefix>; cp.... Сохранность файлов тебе гарантируют только в /etc и в твоем домашнем каталоге. >>

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

<< "не нужно говорить мне что тех -- одно большое глюкало." И не буду, очень хорошая штука. ;-) >>

да вообще-то говоря, так оно и есть. только тссс. это между нами.

<< "трёх, наверное достаточно, чтобы откатиться обратно на rpm/deb/что-то_ещё_там. мне лично нравится простота."

О Чем я и говорю. куда проще ./configure --prefix=/usr/packs/<pack> && make && make install && etml-update-packs ;-) >>

тцтцтц. неа. префиксом ты не обойдёшься :) каждый папакарло придумывает свои хитрые переменные. там могут быть и DESTDIR, и KERNDIR, и {bin,lib,slib,sbin}dir, и {data,man}dir и куча хрензнает ещё чего. и каждый считает, что именно его разблюдовка по директориям верна. я считаю, что верно то, что записано в FHS. наверное я не прав? шучу. ;)

<< ИМХО это подходит для тех, кто действительно не переносит на дух RPM/deb, но хочет следить за пакетами. >>

я написал собственный маленький манагер. конечно же я им не доволен :)

кстати. ещё очень интересная тема: система /etc/rc.d инициализационных скриптов. тоже та ещё песня :)

2logIN: я думал ты поумнея ... :-) но все равно "my niger ..." (С) тарантино .... 2 всяким анонимусам ... отпидарасти сартир лучще ... толку будет больше ... чем привязка к версиям дистров .... кстати я использовал слаку с 1993 года ... хороший был дистр до версии 8.0 но ничто не стоит на месте ... и вот уже как полтора года как перешел на gentoo ... slack rulezzzzzzzz 4444444444444444444444.........evaaaaaaaaaaaaaaaaaaa 22222222222222222222222222222...... но .... :-|

вот кстати ссылка на то, что сделали до тебя logIN: http://freshmeat.net/projects/epkg/?topic_id=41%2C253%2C257%2C861

2 jc (*) (2002-10-14 22:42:47.407) мля всегда найдуться придурки и попытаються изобрести велосипед... portage придурки мля ... portage ...

"стоп. замена пакетов уже не становится тривиальной сменой линка. нужно ещё вызывать etml-update-packs и ждать. кроме того, нужно помнить после каких пакетов нужно запускать etml-update-packs, а после каких -- нет. кажется этот плюс исчезает. "

first.. relax. дышим спокойно, ровномерно ;-))
etml-update-packs работает быстро, запускай его хоть в crond ;-))

--
"ой, да что ты? правда? а откуда новые юзеры появляются в /etc/passwd при установке демонов (fcron, например) знаешь? прально. их создают пакманагеры по пост-ин скриптам. ну или инстал.ш в скаквейр. "

Еще раз, спокойствие на лице.
Видимо тут недопонимание. Я же сказал "добовлять" пакет _может_. Но не изменять с целью удаления чего-либо из файла. Nvidia драйвера тоже добавляют себя в /etc/rc.d/rc.local и это нормально. Но Nvidia не посмеет удалит от туда что-либо другое.
Представь, что я потратил на написание конфига целый день.. прошло 3 года.. я забыл про этот конфиг и решил обновить пакет который заведует этим файлом. Пакет обновил - файла нету, новый пакет работает плохо. Что я делаю? Ставлю старый пакет и снова пишу конфиг? Нет уж.
Конфиги - это мое личное, никто это удалять не имеет права.

--
"остынь. это не изменение оригинального пакета, а расширение его
аддонами. в принципе, каждый аддон можно оформить ввиде пакета и ставить его. но вот не задача: поставляются-то они в виде тривиальных архивов, которые предлагается просто скопировать внутрь теха, а после вызвать несколько команд для реконфигурации. кстати. файлы конфигурации сидят там же, внутри /usr/share/texmf. ку?"

Опять двадцать пять за рыбу деньги - добавление файла в каталог занятый другой программой, не гарантирует сохранность этого файла. для этого существуют /home/<login>/.<твои конфиги>, если у программы нету такой фичи, как user-defined configs, значит левая программа. Я сужу по проверенным. У bash есть /etc/profile, а есть ~/.bash_profile для _моих личных_ конфигов.

--
"а Мы эта... Мы рут :) "

Плохо. Рут нужен только для vi /etc/<something> или make install. Все остальное - нарушение unix-концепции.
Я конечно понимаю, что привычка с Win98, вечно ходить с полными правами, осталась, но надо исправляться.
Вы, конечно, можете быть кем угодно, но _любой_ более или менее опытный unix-пользователь, подтвредит мои слова.

--
"тцтцтц. неа. префиксом ты не обойдёшься :) каждый папакарло придумывает свои хитрые переменные. там могут быть и DESTDIR, и KERNDIR, и {bin,lib,slib,sbin}dir, и {data,man}dir и куча хрензнает ещё чего. и каждый считает, что именно его разблюдовка по директориям верна. я считаю, что верно то, что записано в FHS. наверное я не прав? шучу. ;) "

Еще разок, спокойно.
Кто говорил, что это _для всех_? LFS это для всех? Это для тех, кто знает куда нужно писать --prefix а куда DESTDIR. Данная структура каталога только облегчает управление пакетами LFS-like систем.
В любом отличном от RPM/deb случае, тебе придеться указывать эти DESTDIR. Мы сейчас говорим full-source-based linux? Это значит tar -xzvf .tar.gz && [./configure] && make [DESTDIR=] && su -c "make install"
Изначально никаких RPM/deb нету.

--
"я написал собственный маленький манагер. конечно же я им не доволен :)
кстати. ещё очень интересная тема: система /etc/rc.d инициализационных скриптов. тоже та ещё песня :)"

Странно, я доволен. ;-)
А на счет rc.d , rc.d жив, и думаю еще немножко поживет.

"http://freshmeat.net/projects/epkg/?topic_id=41%2C253%2C257%2C861";

Это похоже, но это в корне не то. Это целый пакетный менеджер. Я же просто устанавливаю проги в отдельный каталог.
"No one can manage packages but me." (c) девиз ;-))

--
"мля всегда найдуться придурки и попытаються изобрести велосипед... portage придурки мля ... portage"

Почему изобрести? Представь, я ничего не знал о epkg, но сделал _почти_ также. Просто без документации. Еслиб я почитал про epkg, а потом сделал также, и сказал - "посмотрите на epkg", чтонибуть изменилось бы ;-))

--
p.s. вся вышесказаная идея не моя, как предпологалось раньше, отдаю должное epkg-developer'aм. ;-))

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

на сегодняшний день я попробовал:

пакменеджмент: rpm, deb, tgz (a la slack), symlink (a la encap), portage (a la bsd ports). ни один из них не устраивает в силу разных причин. наиболее близок -- slack-style. сейчас использую доработанный slack-style (из дополнений compilation-on-the-fly, patching, platform orientation).

бут-скрипты: bsd-style, sysV-style, sysV-style+chkconfig, gentoo-style. наиболее близок gentoo-style, однако использую sysV+chkconfig.

воооот.