GNU убирает соединение всех файлов только вместо двоичного файла
Идея № 1 - каталог уже существует
Попытайтесь выполнить команду rpm -Uvh --test /Downloads/crontabs-1.10-33.el6.noarch.rpm сначала, чтобы видеть, сообщает ли это о чем-либо необычном. Если не затем делают обновление этого пакета вместо установки.
Я полагаю, что это жалуется, потому что этот каталог уже существует, но это неясно кого. На моих полях CentOS 6 этот каталог показывает как принадлежавший пакету cronie.
$ rpm -qf /etc/cron.d
cronie-1.4.4-7.el6.x86_64
Когда я смотрю на содержание crontabs пакет я вижу следующее содержание:
$ repoquery -l crontabs
/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/cron.weekly
/etc/crontab
/usr/bin/run-parts
/usr/share/man/man4/crontabs.4.gz
Уведомление там нет /etc/cron.d. При выполнении следующей команды однако, Вы будете видеть это crontabs требует следующих ресурсов:
$ rpm -qp --requires crontabs-1.10-33.el6.noarch.rpm
/bin/bash
/etc/cron.d
config(crontabs) = 1.10-33.el6
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
Идея № 2 - проверяет cronie пакет
Таким образом, это - то, куда требование прибывает из. Я выполнил бы следующую команду, чтобы подтвердить что пакет cronie правильно установлен:
$ rpm -V cronie --verbose
......... /etc/cron.d
......... /etc/cron.d/0hourly
......... c /etc/cron.deny
......... c /etc/pam.d/crond
......... /etc/rc.d/init.d/crond
......... c /etc/sysconfig/crond
......... /usr/bin/crontab
......... /usr/sbin/crond
......... /usr/share/doc/cronie-1.4.4
......... d /usr/share/doc/cronie-1.4.4/AUTHORS
......... d /usr/share/doc/cronie-1.4.4/COPYING
......... d /usr/share/doc/cronie-1.4.4/ChangeLog
......... d /usr/share/doc/cronie-1.4.4/INSTALL
......... d /usr/share/doc/cronie-1.4.4/README
......... d /usr/share/man/man1/crontab.1.gz
......... d /usr/share/man/man5/crontab.5.gz
......... d /usr/share/man/man8/cron.8.gz
......... d /usr/share/man/man8/crond.8.gz
......... /var/spool/cron
Однако, я считаю, что ваш подход в корне неверен, что делает вашу жизнь ненужно трудной. Проблема в том, что вы не различаете файлы, необходимые во время сборки, и файлы, необходимые во время выполнения. Каталоги типа [1175726]~/local/stow/dwm-6.0/[1175727] представляют собой каталоги пакетов
[1175909], которые должны содержать [1175910]установочные образы, а не исходный код или другие ресурсы, предназначенные только для использования во время сборки.
Правильный рабочий процесс выглядит следующим образом:
Загрузите исходный код в каталог, полностью игнорируемый Stow (например, [1175912]~/src[1175913]).
Убедитесь, что [1175918]~/local/stow/dwm-6. 0/[1175919] содержит только файлы каталогов, необходимые во время выполнения (файлы в разделе [1175920]bin/[1175921], [1175922]man/[1175923] и т.д.)
stow dwm-6.0
См. B. Комнес ' 10.10.14 запись в блоге «GNU Stow Include Files» . Подводя итог, можно сказать, что регулярное выражение:
^ ((?! (\ /) Bin | include | lib | lib64 | local | sbin | share | tmp).) * $
в глобальном списке игнорирования сохранит "только" эти (bin, include и т. д.) каталоги.
Похоже, вы загружаете каталоги с исходным кодом в них.
Используйте configure (или любую другую систему сборки, которую использует программное обеспечение) и вместо этого установите префикс установки в каталоге stow . Запустите make и make install , а затем загрузите установленную программу.
Вот как должно было использоваться укрытие ...