На одной машине вы можете одновременно работать с одним X-сервером, поскольку только тот, чей виртуальный терминал активен, будет перерисовывать контент.
Но возможны установки с несколькими головками с одним и тем же X-сервером с двумя дисплеями, которые не «видят» себя (т.е. один пользователь не может получить доступ к другому дисплею и наоборот). Я не помню точный способ сделать это (давно ...), и большинство конфигураций с несколькими головками предназначены для одного и того же пользователя, использующего обе головы, но также работает другая версия (по крайней мере, работала в прежние времена, когда xinerama был на высоте, а рандр еще не вышел).
Эти зависимости, перечисленные в rpm -qp -requires <pkg>.rpm
, являютсявиртуальными пакетами , если в файле <pkg>.spec
указаны автоматические зависимости . Эти виртуальные пакеты НЕ являются библиотекой soname
, а просто именами виртуальных пакетов (, даже если они выглядят какsoname
).
напр. на Fedora 27 это работает
$ rpm -q --whatprovides "libQt5Core.so.5()(64bit)"
qt5-qtbase-5.9.2-5.fc27.x86_64
но это не
$ rpm -q --whatprovides libQt5Core.so.5
no package provides libQt5Core.so.5
$ rpm -q --whatprovides libQt5Core
no package provides libQt5Core
$ rpm -q --whatprovides Qt5Core
no package provides Qt5Core
Если ваш собственный <pkg>.rpm
сам объединяет библиотеки (, то есть предоставляет эти виртуальные пакеты ), тогда RPM не будет жаловаться, если эти виртуальные пакеты не установлены в системе, поскольку они поставляются с вашим пакетом.
Я не хочу, чтобы rpm автоматически обрабатывал эти зависимости; вы можете использовать:
AutoReqProv: no
Тем не менее, я несколько раз упаковывал свои бинарные файлы и библиотеки, от которых они зависят; rpm никогда не доставлял мне никаких проблем в этом отношении; может ваш способ упаковки не оптимален?
Для дальнейшего чтения об автоматических зависимостях:http://ftp.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html