1 Тема от cdrw

  • cdrw
  • Гость

Многие пользователи "заболевают" желанием установить систему в минимальной комплектации, чтобы затем самому наращивать ее, путем добавления только нужных пакетов.
Тем самым, держа систему под контролем и предотвращая превращение системы в захламленную "кладовку".
Не избежал этой эпидемии и я.
Мне нужна была минимальная работоспособная система, чтобы сразу после установки я смог выйти в интернет и начать доустанавливать только нужные мне пакеты.
В качестве DE я выбрал LXDE, то есть с дистрибутива были установлены пакеты из каталогов /a /ap /d /l /n /x...
Еще в дистрибутив были добавлены каталоги /extra и /lxde. Но это уже дополнение, в котором пакеты не входящие в официальный дистрибутив, такие как lxde, шрифты и aspell-ru, собранный предварительно google-chrome...
За прообраз был взят дистрибутив SalixOS-XFCE-14.0. Список устанавливаемых пакетов из каталогов /core и /basic.
Затем были добавлены некоторые пакеты для работоспособности браузера google-chrome.
Прилагаю архив с тегами для установки минимальной системы дистрибутива Slackware-14.0.

Скачать пакет slackware-14.0_tags.tar.bz2 .

Если кому интересно, могу описать как интегрировать свои каталоги в инсталляционный дистрибутив на примере каталогов /extra и /lxde.
Но это уже отдельная история.
Хотелось бы ещё "подчистить" каталог /n.
Лично мне от сети нужно только подключение по dhcpcd и wifi. ВСЕ!!!
Не хочу, чтобы у меня мертвым грузом лежали на винте пакеты, которые я не использую.
Если уж нужен будет какой либо пакет, лучше добавить его осознанно, заодно узнав для чего он нужен.
Вот и все, чем я хотел поделиться.
Приветствуются советы, пожелания, замечания.

2 Ответ от bormant (04.03.2013 22:15:28 отредактировано bormant)

  • bormant
  • bormant
  • Модератор
  • Неактивен
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,532
  • Репутация : [ 206 | 1 ]

1)

vam/tagi/a/tagfile
aaa_elflibs:SKP

Зря. Нужно объяснять, почему для него лучше ADD?

2)

vam/tagi/a/tagfile
glibc-solibs:SKP
vam/tagi/a/tagfile
glibc:ADD

-solibs пакеты содержат только .so и не содержат дополнительных файлов по отношению к родительским пакетам (которые нужны для сборки), но позволяют сохранить работоспособность на случай полного удаления серии D. Поэтому -solibs лучше включать.

3 Ответ от cdrw

  • cdrw
  • Гость
bormant пишет:

vam/tagi/a/tagfile
aaa_elflibs: SKP

Зря. Нужно объяснять, почему для него лучше ADD?

Старые библиотеки, используемые некоторыми старыми программами?
Добавлю для себя.
Здесь теги перекочевали прямо из SalixOS, я ещё не просматривал попакетно.
Спасибо за подсказку. bs

4 Ответ от bormant

  • bormant
  • bormant
  • Модератор
  • Неактивен
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,532
  • Репутация : [ 206 | 1 ]

Нет, не старые. Это сборник "обычно нужных .so" из других пакетов. Каких? А вот этих (кроме aaa_elflibs):

$ grep -Rlf <(grep \.so /var/log/packages/aaa_elflibs-14.0-x86_64-4) /var/log/packages | sort
/var/log/packages/aaa_elflibs-14.0-x86_64-4
/var/log/packages/acl-2.2.51-x86_64-1
/var/log/packages/alsa-lib-1.0.26-x86_64-1
/var/log/packages/attr-2.4.46-x86_64-1
/var/log/packages/bzip2-1.0.6-x86_64-1
/var/log/packages/cups-1.5.4-x86_64-2
/var/log/packages/db42-4.2.52-x86_64-3
/var/log/packages/db44-4.4.20-x86_64-3
/var/log/packages/dmapi-2.2.10-x86_64-1
/var/log/packages/expat-2.0.1-x86_64-2
/var/log/packages/fuse-2.8.5-x86_64-1
/var/log/packages/gcc-4.7.1-x86_64-1
/var/log/packages/gdbm-1.8.3-x86_64-4
/var/log/packages/glib2-2.32.4-x86_64-1
/var/log/packages/gmp-5.0.5-x86_64-1
/var/log/packages/gpm-1.20.1-x86_64-5
/var/log/packages/libcap-2.22-x86_64-1
/var/log/packages/libelf-0.8.13-x86_64-2
/var/log/packages/libidn-1.25-x86_64-2
/var/log/packages/libjpeg-v8a-x86_64-1
/var/log/packages/libpng-1.4.12-x86_64-1
/var/log/packages/libtermcap-1.2.3-x86_64-7
/var/log/packages/libtiff-3.9.6-x86_64-1
/var/log/packages/libtool-2.4.2-x86_64-1
/var/log/packages/libusb-1.0.9-x86_64-1
/var/log/packages/libusb-compat-0.1.4-x86_64-1
/var/log/packages/lvm2-2.02.96-x86_64-4
/var/log/packages/mm-1.4.2-x86_64-2
/var/log/packages/ncurses-5.9-x86_64-1
/var/log/packages/openldap-client-2.4.31-x86_64-2
/var/log/packages/pcre-8.12-x86_64-1
/var/log/packages/popt-1.7-x86_64-3
/var/log/packages/readline-5.2-x86_64-4
/var/log/packages/slang1-1.4.9-x86_64-1
/var/log/packages/slang-2.2.3-x86_64-1
/var/log/packages/svgalib-1.9.25-x86_64-2
/var/log/packages/sysfsutils-2.1.0-x86_64-1
/var/log/packages/xz-5.0.4-x86_64-1
/var/log/packages/zlib-1.2.6-x86_64-1

То есть, если на системе не нужно ничего собирать, то вместо вон тех пакетов достаточно одного aaa_elflibs, в нем собраны .so из тех пакетов.

5 Ответ от cdrw

  • cdrw
  • Гость
bormant пишет:

То есть, если на системе не нужно ничего собирать, то вместо вон тех пакетов достаточно одного aaa_elflibs, в нем собраны .so из тех пакетов.

Очень ценные замечания. (включая все Ваши посты)
Спасибо!
У меня многое получается как то интуитивно, Ваши же пояснения ставят всё на свои места.
Озвучиваете то, что я никак не могу собрать "в кучку"...
Просто стимулируете заниматься своим хобби...
Не сочтите за лесть, но приятно, когда тебя замечают и помогают.  ay

6 Ответ от bormant

  • bormant
  • bormant
  • Модератор
  • Неактивен
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,532
  • Репутация : [ 206 | 1 ]

Возвращаясь к aaa_elflibs -- обратите внимание, он никогда потом в дистрибутиве не обновляется (в patches), если не считать обновления на следующий выпуск дистрибутива. Так сделано, чтобы он не затер своими, возможно уже устаревшими, версиями .so те, что установлены позже с обновленными пакетами. Ах да, наличие .so еще не делает доступны сами утилиты, например, без установки пакета bzip2 сами команды из него не доступны, но то, что слинковано с libbzip.so уже будет иметь зависимость установленной и будет работоспособно.
Состав aaa_elflibs от версии к версии корректируется, чтобы обеспечить как можно больше наиболее необходимых зависимостей для прочих пакетов.
Отчасти, это один из слакваревых вариантов уменьшения связности пакетов.

7 Ответ от cdrw

  • cdrw
  • Гость
bormant пишет:

наличие .so еще не делает доступны сами утилиты, например, без установки пакета bzip2 сами команды из него не доступны, но то, что слинковано с libbzip.so уже будет иметь зависимость установленной и будет работоспособно.

По этому поводу такой вопрос.
Я так понимаю, есть два вида зависимостей - прямая и относительная. Прямая, это когда пакет использует какую то библиотеку из другого пакета и работать без этого физически не может.
Но есть ещё такая штука, пример - vlc медиапакет. При компиляции требует множество "установленных" пакетов, но скомпилированный уже, не требует их наличия в системе.
Я это назвал для себя относительной зависимостью. Интересует механизм этого действия. Конкретное примененение - желание скомпилировать DE LXDE на системе, где сам LXDE не установлен.

8 Ответ от bormant

  • bormant
  • bormant
  • Модератор
  • Неактивен
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,532
  • Репутация : [ 206 | 1 ]

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

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

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


ps.

cdrw⇓ пишет:

скомпилировать DE LXDE на системе, где сам LXDE не установлен.

http://slackware.ponce.cc/blog/2010/08/ … th-sbopkg/
В сухом остатке:

# cat <<EOF > /var/lib/sbopkg/queues/lxde.sqf
leafpad
xarchiver | BEND_ME_OVER=kthxbai
openbox
xmms2
gpicview
lxappearance
lxappearance-obconf
lxde-common
lxrandr
lxterminal
menu-cache
lxmenu-data
lxlauncher
lxpanel
lxpanel-xmms2
lxtask
lxpolkit
lxsession
lxsession-edit
vala
libfm
pcmanfm
lxshortcut
lxinput
lxmusic
lxdm
libgee
gksu-polkit
EOF
# sbopkg -Rri lxde.sqf

9 Ответ от cdrw

  • cdrw
  • Гость
bormant⇓ пишет:

-solibs пакеты содержат только .so и не содержат дополнительных файлов по отношению к родительским пакетам (которые нужны для сборки), но позволяют сохранить работоспособность на случай полного удаления серии D. Поэтому -solibs лучше включать.

Все файлы из этого пакета входят в основной пакет glibc. Видимо поэтому разработчики SalixOS исключили пакет из установочного набора пакетов.

10 Ответ от bormant

  • bormant
  • bormant
  • Модератор
  • Неактивен
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,532
  • Репутация : [ 206 | 1 ]
cdrw⇓ пишет:

Все файлы из этого пакета входят в основной пакет glibc. Видимо поэтому разработчики SalixOS исключили пакет из установочного набора пакетов.

А теперь представьте, всё уже собрано (или теперь будет собираться на другой машине), толстенный пакет glibc больше не нужен, делаете "removepkg glibc" и... Баста, приехали, сломалось всё! А вот если glibc-solibs установлен, всё по-прежнему работает (это и есть основная задача пакетов -solibs, обеспечение работоспособности в отсутствие толстых девелоперских пакетов).

11 Ответ от cdrw

  • cdrw
  • Гость
bormant⇓ пишет:

Баста, приехали, сломалось всё! А вот если glibc-solibs установлен, всё по-прежнему работает

Вот этого я понять как раз и не могу. Ерунда какая то получается.
Есть два пакета - А и Б.
В пакет А входит файл a, а в пакет Б входят фаилы a, b и c...
И их установили поочерёдно - сначала А, потом Б.
Каким образом можно удалить пакет Б, с помощью примитивного по сути pkgtool, чтобы он не трогал файл a?
Я думаю, дело обстоит по другому.
Патрик, ради минимизации размера каталога /a, сделал пакет с необходимым минимумом от glibc, обеспечивающий работоспособность системы пакетов в каталоге /a.
При расширении системы, glibc-solibs "перекрывается" полным пакетом glibc!
И удаление невозможно без ущерба для работоспособности, а вот обновление - пожалуйста.
Так что glibc-solibs нужен только если нужна только базовая систем из каталога /a.
Другого я объяснения не вижу.

12 Ответ от bormant

  • bormant
  • bormant
  • Модератор
  • Неактивен
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,532
  • Репутация : [ 206 | 1 ]

cdrw,
pkgtools (в частности installpkg/upgradepkg/removepkg) не настолько примитивны, как вы о них думаете. removepkg не удаляет файл с диска до тех пор, пока есть хоть один пакет, содержащий файл (по имени, включая полный путь).
Да, если разные пакеты ставят по одному имени _разные_ файлы -- такая ситуация специально не отслеживается, выживает последний из установленных.

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

Если на конкретной системе ПО не собирают, а ставят из готовых бинарных пакетов, на ней не нужен glibc, достаточно glibc-solibs (а если нет ПО, динамически связанного с glibc, то не нужен и glibc-solibs). Для парка систем достаточно одной сборочной машины.

cdrw⇓ пишет:

Я думаю, дело обстоит по другому.

PACKAGE NAME:     glibc-solibs-2.15-x86_64-7
COMPRESSED PACKAGE SIZE:     2.6M
UNCOMPRESSED PACKAGE SIZE:     11M
PACKAGE LOCATION: /var/log/mount/slackware64/a/glibc-solibs-2.15-x86_64-7.txz
PACKAGE DESCRIPTION:
glibc-solibs: glibc-solibs (shared GNU C libraries)
glibc-solibs:
glibc-solibs: This package contains the shared libraries, binaries, and support
glibc-solibs: files required to run most Linux applications linked with glibc.

PACKAGE NAME:     glibc-2.15-x86_64-7
COMPRESSED PACKAGE SIZE:     12.0M
UNCOMPRESSED PACKAGE SIZE:     141M
PACKAGE LOCATION: /var/log/mount/slackware64/l/glibc-2.15-x86_64-7.txz
PACKAGE DESCRIPTION:
glibc: glibc (GNU C libraries)
glibc:
glibc: This package contains the GNU C libraries and header files.  The GNU
glibc: C library was written originally by Roland McGrath, and is currently
glibc: maintained by Ulrich Drepper.  Some parts of the library were
glibc: contributed or worked on by other people.
glibc:
glibc: You'll need this package to compile programs.

Теперь разница видна лучше? Экономия на 2,6Мб против 12,0Мб пакета или всё же на 11Мб против 141Мб в системе?

13 Ответ от bormant

  • bormant
  • bormant
  • Модератор
  • Неактивен
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,532
  • Репутация : [ 206 | 1 ]

Вот простая иллюстрация к сказанному про установку удаление:

# mkdir -p /tmp/package-test/home/test; cd /tmp/package-test
# echo file1 > home/test/file1
# echo file2 > home/test/file2
# makepkg -c y /tmp/test-0.1-noarch-1.txz
...
Slackware package ../test-0.1-noarch-1.txz created.

# rm home/test/file2
# makepkg -c y /tmp/test-part-0.1-noarch-1.txz
...
Slackware package /tmp/test-part-0.1-noarch-1.txz created.
# installpkg /tmp/test-part-0.1-noarch-1.txz
# find /home/test
/home/test/
/home/test/file1

# installpkg /tmp/test-0.1-noarch-1.txz
# find /home/test
/home/test/
/home/test/file1
/home/test/file2
# removepkg test
Removing package /var/log/packages/test-0.1-noarch-1...
Removing files:
  --> /home/test/file1 was found in another package. Skipping.
  --> Deleting /home/test/file2

# find /home/test
/home/
/home/test/
/home/test/file1

# removepkg test-part
Removing package /var/log/packages/test-part-0.1-noarch-1...
Removing files:
  --> Deleting /home/test/file1
  --> Deleting empty directory /home/test/

Если появились вопросы, с удовольствием отвечу.

14 Ответ от cdrw

  • cdrw
  • Гость
bormant⇓ пишет:

Если появились вопросы, с удовольствием отвечу.

Пример понятен, только я как "Фома неверующий" поищу этот участок кода в скрипте.
Когда понятен механизм, многие вопросы отпадают сразу сами.
Я только что обновил на старом компе перекомпилированный под athlon-xp glibc.
И glibc-solibs, естественно не обновлял, будучи уверенным, что всё равно glibc перезапишет файлы пакета glibc-solibs.
А вопросы ещё будут, обязательно. Вы очень хорошо объясняете, обращая внимание на неожиданные стороны проблемы.
Я потихоньку "созреваю" для lfs...
Естественно, только с pkgtool в качестве завхоза.  ab
Так что вопросы будут.

15 Ответ от bormant

  • bormant
  • bormant
  • Модератор
  • Неактивен
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,532
  • Репутация : [ 206 | 1 ]
cdrw⇓ пишет:

Я только что обновил на старом компе перекомпилированный под athlon-xp glibc.
И glibc-solibs, естественно не обновлял, будучи уверенным, что всё равно glibc перезапишет файлы пакета glibc-solibs.

Если версия та же, а изменялись только ключи configure и/или CFLAGS/CXXFLAGS, то перезапишет (ведь имена файлов получатся теми же самыми), и числиться эти файлы будут за обоими пакетами, и установленный glibc-solibs не даст удалить критичные библиотеки.
А если версия другая настолько, что .so получились с другими именами, тогда есть смысл 1) сделать -solobs соответствующей версии и 2) разобраться с символьными ссылками на библиотеки (см. doinst.sh).