[накидайте ссылки] формат пакетов

опять же, это никак не ответ на вопрос о поиске зависимостей

Да, вот тебе точно-то стоит прнять разупорину.

1. rpm умеет находить нужную зависимость по полю Provides в свойствах пакета.
2. apt-get умеет находить нужную зависимость по полю Provides в свойствах пакета.
3. pacman умеет находить нужную зависимость по полю Provides в свойствах пакета.

Найди все отличия, you are welcome.

это никак не ответ на вопрос о поиске зависимостей

Это вполне отвечает на вопрос, если у тебя есть мозг в голове. Разрешение зависимостей осуществляется по абстрактным именам, которые могут быть именами пакетов, а могут ими и не быть. Поиск осуществляется по индексу репозитория.

Но если с сообразительностью проблемы, просто сходи и ознакомься с матчастью.

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

=Pkg: flash-player 11.1.102.62 1.5 x86_64
=Cks: SHA256 8d79c05537a3209f165cbb5a9c636f0565e1c9eb9f89648ed8ba7abc74750c73
+Req:
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libX11.so.6()(64bit)
libXext.so.6()(64bit)
libXt.so.6()(64bit)
libasound.so.2()(64bit)
libatk-1.0.so.0()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libcairo.so.2()(64bit)
libcurl.so.4()(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libfontconfig.so.1()(64bit)
libfreetype.so.6()(64bit)
libgdk-x11-2.0.so.0()(64bit)
libgdk_pixbuf-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgmodule-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libgtk-x11-2.0.so.0()(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libnspr4.so()(64bit)
libnss3.so()(64bit)
libnss3.so(NSS_3.10)(64bit)
libnss3.so(NSS_3.11)(64bit)
libnss3.so(NSS_3.12)(64bit)
libnss3.so(NSS_3.2)(64bit)
libnss3.so(NSS_3.3)(64bit)
libnss3.so(NSS_3.4)(64bit)
libnss3.so(NSS_3.6)(64bit)
libnss3.so(NSS_3.9)(64bit)
libnss3.so(NSS_3.9.2)(64bit)
libnssutil3.so()(64bit)
libpango-1.0.so.0()(64bit)
libpangocairo-1.0.so.0()(64bit)
libpangoft2-1.0.so.0()(64bit)
libplc4.so()(64bit)
libplds4.so()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
libpthread.so.0(GLIBC_2.3.3)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
libsmime3.so()(64bit)
libsmime3.so(NSS_3.2)(64bit)
libsmime3.so(NSS_3.4)(64bit)
libssl3.so()(64bit)
libssl3.so(NSS_3.2)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsLzma) <= 4.4.6-1
-Req:
+Prv:
flash-plugin = 11.1.102.62
libflashplayer.so()(64bit)
libflashsupport = 1.2
libflashsupport-32bit = 1.2
netscape-plugins
flash-player = 11.1.102.62-1.5
flash-player(x86-64) = 11.1.102.62-1.5
-Prv:
+Obs:
libflashsupport <= 1.2
libflashsupport-32bit <= 1.2
netscape-plugins
-Obs:
=Grp: Productivity/Networking/Web/Browsers
=Lic: NON-OSI-COMPLIANT(royalties)
=Vnd: openSUSE
=Src: flash-player 11.1.102.62 1.5 nosrc
=Tim: 1331429301
=Loc: 1 flash-player-11.1.102.62-1.5.x86_64.rpm
=Siz: 5050595 18823156
=Shr: flash-player 11.1.102.62 1.5 i586

а вот что содержится в Packages.gz деб репа

Package: flashplugin-nonfree
Priority: optional
Section: contrib/web
Installed-Size: 132
Maintainer: Bart Martens <bartm@debian.org>
Architecture: i386
Version: 1:2.8.2
Replaces: flashplugin (<< 6)
Depends: debconf | debconf-2.0, wget, gnupg, libatk1.0-0, libcairo2, libfontconfig1, libfreetype6, libgcc1, libglib2.0-0, libgtk2.0-0, libnspr4-0d, libnss3-1d, libpango1.0-0, libstdc++6, libx11-6, libxext6, libxt6, libcurl3-gnutls
Suggests: iceweasel, konqueror-nsplugins, x-ttcidfont-conf, msttcorefonts, ttf-dejavu, ttf-xfree86-nonfree, flashplugin-nonfree-extrasound
Conflicts: flashplayer-mozilla, flashplugin (<< 6), libflash-mozplugin, xfs (<< 1:1.0.1-5)
Filename: pool/contrib/f/flashplugin-nonfree/flashplugin-nonfree_2.8.2_i386.deb
Size: 17874
MD5sum: 9788f4cc911a5f4abfba8e74d7a88786
SHA1: ad91ce076ebe01603c0527e5a0a304e2770e875b
SHA256: 1f84a6541299a33edf7c9e1cf0d94f75ffa08e3af5113a150971d06b84960901
Description: Adobe Flash Player - browser plugin
 This package will download the Flash Player from Adobe.  It is a
 Netscape/Mozilla type plugin.  Any browser based on Netscape or Mozilla can
 use the Flash Player.  This package currently supports the following browsers:
 Mozilla, Mozilla-Firefox, Firefox, Iceweasel, and Iceape.  Also Galeon and
 Epiphany can use the Flash Player.  Konqueror can also use the Flash Player if
 konqueror-nsplugins is installed.
 .
 WARNING: Installing this Debian package causes the
 Adobe Flash Player to be downloaded from www.adobe.com.
 The End User License Agreement of the Adobe Flash Player
 is available at www.adobe.com.
Homepage: http://wiki.debian.org/FlashPlayer
Tag: role::plugin, suite::mozilla, use::browsing

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

Поиск осуществляется по индексу репозитория.

и это механизм ПМ!
политика дистра будет бесполезна, если в ПМ нет такой возможности!

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

Давай ты сначала покажешь, где rpm хранит список файлов пакета. В твоём листинге я никакого списка файлов не вижу. Вижу только поле Prv с виртуальными именами, которые в терминах rpm называются capabilities, кстати.

я говорил не про пакман
а про сферический ПМ, который не умеет искать по этому полю или ему аналогичному

Это твои личные трудности. Тред посвящен реальным ПМ, а не плодам твоего воображения.

твои трудности в том, что ты не понимаешь, что и где делается
политика дистра может только выбрать из того функционала, что есть в ПМ
если нет поиска, то без запиливания в ПМ это работать не будет
пойми ты это уже наконец!
хватит выставлять себя на посмешище

Блеать, протри глаза и прочитай третий коммент треда:

в RPM зависимости определяются по именам файлов внутри пакетов, а в DEB ― по именам пакетов

Речь идет про реальные пакетные менеджеры, и у них ЕСТЬ ЭТА ФИЧА, она не уникальна для rpm. Что я и пытаюсь уже полдня пояснить rpm-щикам. Нет, прибежал гентушник, и сходе начал истекать влажными мечтами о каких-то сферических ПМах. Иди проспись.

я ответил вот на этот бред

«Зависимости от файлов» это вопрос политики дистрибутива, а не механизма пакетного менеджера.

теперь проспись ты и пойми - это механизм ПМ!
если есть варианты 1 и 2 запиленные в ПМ, то что выбрать - политика дистра, да
но от этого ни один из вариантов не перестаёт быть механизмом ПМ
хватит пародировать свою аву

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

вся суть в том как арч или деб мне найдут libflashplayer.so

Помести в список Provides, и найдут.

Вручную? rpm даже при опакечивании приопритарщины сам находит и прописывает зависимости и provides для бинарей. А тут нужно все вручную, очень удобно.
Тоесть можно сделать как в rpm, но ни какой инфраструктуры для этого нет, можно просто ручками прописывать для разнообразия.

Вручную? rpm даже при опакечивании приопритарщины сам находит и прописывает зависимости и provides для бинарей

Процедура сборки вторична по отношению к формату пакета и к пакетному менеджеру отношения не имеет, не? Заметь, что для этой фичи ничего не придётся в пакетном менеджере менять, просто скрипты пакетирования поправить.

инфраструктуры для этого нет

Отсутствует потому что не требуется в дистрибутивах.

Стоп! Это что получается, в DEB'ах нет аналогичной фичи:

$ yum provides */palimpsest

Как вы утомили...

1. Её и в ваших федорах нет для произвольного файла!
2. В метадате deb точно такое же поле Provides, как и в rpm. Бери и пользуйся.

Для произвольного файла из пакета, содержащегося в репозитории (пусть даже и не установленного в системе), точно есть!

Для произвольного файла из пакета, содержащегося в репозитории

Но зависимости-то ты по ним отслеживать не можешь.

Да ну?

$ yum provides */palimpsest
Загружены модули: langpacks, presto, refresh-packagekit
gnome-disk-utility-3.0.2-3.fc16.i686 : Disk management application
Источник: fedora
Совпадения с:
Имя файла   : /usr/share/gnome/help/palimpsest
Имя файла   : /usr/share/omf/palimpsest
Имя файла   : /usr/bin/palimpsest



gnome-disk-utility-3.0.2-3.fc16.i686 : Disk management application
Источник: @anaconda-0
Совпадения с:
Имя файла   : /usr/bin/palimpsest



$ yum deplist gnome-disk-utility
Загружены модули: langpacks, presto, refresh-packagekit                                              
Поиск зависимостей:                                                                                  
пакет: gnome-disk-utility.i686 3.0.2-3.fc16                                                          
  зависимость: /bin/sh                                                                               
   provider: bash.i686 4.2.20-1.fc16                                                                 
  зависимость: gnome-disk-utility-libs = 3.0.2-3.fc16
   provider: gnome-disk-utility-libs.i686 3.0.2-3.fc16
  зависимость: libX11.so.6
   provider: libX11.i686 1.4.3-1.fc16
  зависимость: libatasmart.so.4
   provider: libatasmart.i686 0.17-3.fc15
  зависимость: libatk-1.0.so.0
   provider: atk.i686 2.2.0-2.fc16
  зависимость: libavahi-client.so.3
   provider: avahi-libs.i686 0.6.30-4.fc16
  зависимость: libavahi-common.so.3
   provider: avahi-libs.i686 0.6.30-4.fc16
  зависимость: libavahi-glib.so.1
   provider: avahi-glib.i686 0.6.30-4.fc16
  зависимость: libavahi-ui-gtk3.so.0
   provider: avahi-ui-gtk3.i686 0.6.30-4.fc16
  зависимость: libc.so.6(GLIBC_2.2)
   provider: glibc.i686 2.14.90-24.fc16.6
  зависимость: libcairo-gobject.so.2
   provider: cairo-gobject.i686 1.10.2-4.fc16
  зависимость: libcairo.so.2
   provider: cairo-freeworld.i686 1.10.2-1.fc16
   provider: cairo.i686 1.10.2-4.fc16
  зависимость: libdbus-1.so.3
   provider: dbus-libs.i686 1:1.4.10-3.fc16
  зависимость: libdbus-glib-1.so.2
   provider: dbus-glib.i686 0.92-2.fc15
  зависимость: libfontconfig.so.1
   provider: fontconfig.i686 2.8.0-4.fc16.1.R
  зависимость: libfreetype.so.6
   provider: freetype-infinality.i686 2.4.8-1.fc16.R
   provider: freetype-freeworld.i686 2.4.6-4.fc16
   provider: freetype.i686 2.4.6-4.fc16.R
  зависимость: libgdk-3.so.0
   provider: gtk3.i686 3.2.3-2.fc16
  зависимость: libgdk_pixbuf-2.0.so.0
   provider: gdk-pixbuf2.i686 2.24.1-1.fc16
  зависимость: libgdu-gtk.so.0
   provider: gnome-disk-utility-ui-libs.i686 3.0.2-3.fc16
  зависимость: libgdu.so.0
   provider: gnome-disk-utility-libs.i686 3.0.2-3.fc16
  зависимость: libgio-2.0.so.0
   provider: glib2.i686 2.30.2-1.fc16
  зависимость: libglib-2.0.so.0
   provider: glib2.i686 2.30.2-1.fc16
  зависимость: libgmodule-2.0.so.0
   provider: glib2.i686 2.30.2-1.fc16
  зависимость: libgnome-keyring.so.0
   provider: libgnome-keyring.i686 3.2.0-1.fc16
  зависимость: libgobject-2.0.so.0
   provider: glib2.i686 2.30.2-1.fc16
  зависимость: libgthread-2.0.so.0
   provider: glib2.i686 2.30.2-1.fc16
  зависимость: libgtk-3.so.0
   provider: gtk3.i686 3.2.3-2.fc16
  зависимость: libm.so.6
   provider: glibc.i686 2.14.90-24.fc16.6
  зависимость: libnotify.so.4
   provider: libnotify.i686 0.7.4-1.fc16
  зависимость: libpango-1.0.so.0
   provider: pango.i686 1.29.4-1.fc16
  зависимость: libpangocairo-1.0.so.0
   provider: pango.i686 1.29.4-1.fc16
  зависимость: libpangoft2-1.0.so.0
   provider: pango.i686 1.29.4-1.fc16
  зависимость: libpng12.so.0
   provider: libpng.i686 2:1.2.46-2.fc16
  зависимость: libpthread.so.0
   provider: glibc.i686 2.14.90-24.fc16.6
  зависимость: libpthread.so.0(GLIBC_2.0)
   provider: glibc.i686 2.14.90-24.fc16.6
  зависимость: librt.so.1
   provider: glibc.i686 2.14.90-24.fc16.6
  зависимость: libunique-3.0.so.0
   provider: unique3.i686 3.0.2-1.fc16
  зависимость: rtld(GNU_HASH)
   provider: glibc.i686 2.14.90-24.fc16.6

Да ну?

Поясни теперь, что сказать хотел.

geekless

Для произвольного файла из пакета, содержащегося в репозитории

Но зависимости-то ты по ним отслеживать не можешь.

Показал, что могу =D

// С уважением, Кэп.

Это не зависимости от файлов. Это зависимости от capabilities.

// С уважением, Кэп.

Шо це «capabilities»?

Из 'man yum':

       deplist
              Produces a list of all  dependencies  and  what
              packages  provide  those  dependencies  for the
              given packages. As of 3.2.30 it now just  shows
              the latest version of each package that matches
              (this can be changed by using --showduplicates)
              and  it  only shows the newest providers (which
              can be changed by using --verbose).

In RPM terminology, each package provides capabilities. A capability is simply a text string that the package claims it provides. In most cases, a capability names a file or a package. But the capability can be any arbitrary text string.

(c) Fedora RPM Guide. Chapter 5. Package Dependencies.

Да какая мне разница, как оно выводит список зависимостей?

Главное, что оно это делает, причём, делает это правильно и для любого пакета, содержащегося в репозиториях, в т.ч. и в RPM-Fusion, RFRemix / etc.

Ты савсэм глюпый, да?

В capabilities попадает ограниченный набор строк. А вовсе не все имена файлов пакета с полными путями. Можешь ты такую простую вещь понять?

Если в DEB-based дистрах мейнтейнеры отличаются халатностью, то никто другой в этом не виноват. У нас-то с этим всё хорошо.

Чо?

И вообще, по Вашей логике, получается, что YUM и зависимости-то не может нормально разрулить что ли? И с чего Вы взяли, что deplist использует эти самые capabilities? Оно вообще-то при обновлении метаданных из репов кучу всего выкачивает, в т.ч. и БД, по которым потом все операции и осуществляет.

В DEB'е же оно использует текстовый список пактов в репе, так? В RPM'ах для этого и много другого используются как раз базы. Именно поэтому можно оперировать с информацией о пакетах, даже не установленных в системе.

См. камент ниже, чо.

в мандриве нормально устанавливались пакеты федоры

Я ниже самофикс сделал:
[накидайте ссылки] формат пакетов (комментарий)

И вообще, по Вашей логике, получается, что YUM и зависимости-то не может нормально разрулить что ли?

По моей логике получается, что если бы ты прочитал мануал, то не писал бы бред про «немогущий yum». Как-то так.

И с чего Вы взяли, что deplist использует эти самые capabilities?

Ваш yum может использовать что угодно. Но вот документация rpm вполне чётко указывает, что он должен использовать.
Как и в любом нормальном менеджере бинарных пакетов, в rpm используется разрешение зависимостей на основе неких условных имён (которые в его терминологии называются capabilities). Вся остальная лирика — это конкретная политика дистрибутива, не имеющая отношения к механизму. Сколько раз я должен повторить эту мысль, чтобы дошло?

В DEB'е же оно использует текстовый список пактов в репе, так?

http://ftp.debian.org/debian/dists/stable/main/binary-i386/Packages.bz2
Ознакомься.

В RPM'ах для этого и много другого используются как раз базы.

Выше по ссылке — как раз база данных.

Оно вообще-то при обновлении метаданных из репов кучу всего выкачивает, в т.ч. и БД, по которым потом все операции и осуществляет.
Именно поэтому можно оперировать с информацией о пакетах, даже не установленных в системе.

Слушай, вот объясни мне простую вещь. Почему пользователи систем с форматом пакетов rpm постоянно выдают тривиальные и поддерживаемые любым нормальнм пакетником фичи за уникальные особенности своей системы? Это проистекает от незнакомства с матчастью? От самоуверенности? От облучения инопланетянами?

Да мне, честно говоря, по фиг достоинства и недостатки того или иного PM'а. Главное, мне нравится RPM, я его и использую.

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

Да пусть там хоть хрен лысый. Если мейнтейнер не забивает на правильность сборки пакетов, то всё будет нормально.

Просто изначально Вы сказали:«Но зависимости-то ты по ним отслеживать не можешь.» Я сказал, что могу. Просто мне нет дела до того, текстовые ли файлы используются или что-то другое для этих целей. Поэтому-то и по фиг на capabilities.

Надеюсь, мысль ясна.

Ты савсэм глюпый, да?

Переход на личности ― это даже как-то совсем не по-взрослому =D

Просто изначально Вы сказали:«Но зависимости-то ты по ним отслеживать не можешь.» Я сказал, что могу.

Всё просто, бро: ты ошибся. Не можешь.

Почему именно не можешь, я тебе уже раза 100500 раз объяснил.

Живите в своём мире.

А у нас, что показывает в выхлопе yum deplist <package_name>, именно это, и ничто другое, будет притянуто по зависимостям при установке <package_name>.

Да и вообще, cast plm!

На выходе yum deplist gnome-disk-utility тебе показывает именно список capabilities и то, какими пакетами они были резолвлены. Никаким списком файлов там и не пахнет. Смотри в прцитированный твой листинг, пока не начнёт наступать прояснение.

Если не начнёт, то попробуй понять, что за файл такой «libc.so.6(GLIBC_2.2)», и (если предположить, что это «файл») почему путь начинается не от корня. Подумай еще раз.

Чтоб ты не мучался, сразу даю ответ: «libc.so.6(GLIBC_2.2)» — это не имя файла.

  зависимость: libpangocairo-1.0.so.0
   provider: pango.i686 1.29.4-1.fc16

libpangocairo-1.0.so.0 ― файл, pango.i686 1.29.4-1.fc16 ― пакет.
В Вашем примере имя файла ― libc.so.6 [без "(GLIBC_2.2)«], я ХЗ зачем нужен параметр (GLIBC_2.2). Может, для точной версии оного.
Именовать зависимости от корня нет нужды, ибо есть переменная PATH. Если в разных репах будут одинаковые файлы в разных пакетах, тогда репы будут несовместимы.

Резолвинг пакетов осуществляется по условным именам. Один пакет говорит «хочу бабу», второй говорит «у меня тут есть баба», пакетник их спаривает. Существует ли баба на самом деле, или это фантастика, пакетному менеджеру абсолютно до фени.

Ты можешь называть capabilities именами пакетов. Ты можешь называть capabilities именами so-шек. Ты можешь называть их именами своих бывших девушек. Пакетному менеджеру абсолютно похрену, как ты их назовёшь. Он не проверяет зависимости пакетов по содержащимся в них файлам. Он в момент резолвинга в гробу видал эти файлы. Ты можешь задекларировать, что твой пакет предоставляет libpangocairo-1.0.so.0, а положить туда порнографию. После такого надругательства гуевые приложения запускаться перестанут, но пакетнику будет похрен.

Я не знаю, как тебе еще объяснять.

И да, ремарка на полях: в процедуре динамической линковки переменная PATH не играет никакой роли. «Если мы не знаем матчасть, то мы не знаем её с размахом.»

Дальше-то что?
Мне это параллельно =D
Зависимости мне deplist всё равно покажет.
И если зависимости будут в репах (не важно, по пакетам или по именам файлов,― по фиг, в общем), то при установке пакета они подтянутся.

Что не так-то?

Что не так-то?

Это:

Просто изначально Вы сказали:«Но зависимости-то ты по ним отслеживать не можешь.» Я сказал, что могу.

Всё просто, бро: ты ошибся. Не можешь.

Я и не скрывал, что я ни разу не IT'шник. Просто я действительно не понимаю, зачем нужны полные имена файлов в зависимостях =D

Ну не участвует PATH в разрешениях зависимостей, значит, у PM'а есть свой механизм поиска, что с того.

Сказка про белого бычка =D

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

Но если они где-либо прописаны и затем помещены в БД, которую использует PM, то я могу просто взять и посмотреть их.

Точка.

Ну не участвует PATH в разрешениях зависимостей, значит, у PM'а есть свой механизм поиска, что с того.

facepalm.so

Давай закончим на этом. Если ты путаешь резолвинг пакетов с резолвингом библиотек динамическим линковщиком, тут просто нечего больше обсуждать.

Но если они где-либо прописаны и затем помещены в БД, которую использует PM, то я могу просто взять и посмотреть их.
Точка.

Там нет ВСЕХ файлов.
Точка.

Какой ещё линковщик при работе PM'а ? 0_o

Пруф.

Почему каждые дистростроители (почти) велосипедят формат пакетов?

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