Если Вы имеете nosharedscripts
набор (значение по умолчанию), и prerotate
выходы сценария с ошибкой затронутый файл журнала не будут иметь дальнейшего действия взятым it*.
Так, в теории у Вас могло быть что-то как (предупреждение, непротестированное):
/var/log/application.log {
nosharedscripts
prerotate
logfile=$1
lsof $logfile >/dev/null
exit $?
endscript
...
}
итак, если lsof
не может найти процессы с $logfile
открытый, prerotate
сценарий выйдет с 1
, и logrotate
не примет мер по тому журналу.
*От logrotate(8)
страница справочника на linux.die.net:
nosharedscripts
Run prerotate and postrotate scripts for every log file which is rotated
(this is the default, and overrides the sharedscripts option). The absolute
path to the log file is passed as first argument to the script. If the
scripts exit with error, the remaining actions will not be executed for the
affected log only.
...
prerotate/endscript
The lines between prerotate and endscript (both of which must appear on
lines by themselves) are executed (using /bin/sh) before the log file is
rotated and only if the log will actually be rotated. These directives may
only appear inside a log file definition. Normally, the absolute path to
the log file is passed as first argument to the script. If sharedscripts is
specified, whole pattern is passed to the script. See also postrotate. See
sharedscripts and nosharedscripts for error handling.
Это может быть иждивенцем на Вашем logrotate
версия, но я не могу найти документацию, на которой версии делают / не ведут себя этот путь.
Нет. Если Вы не убеждаете packagekit поддерживать не только главные диспетчеры пакетов (APT, об/мин, pacman), но также и определенные для языка (RVM, CPAN, npm и т.д....), это не находится в программе никакого дистрибутива.
Диспетчеры пакетов как этот легко установить и настроить, я не полагаю, что необходимо было бы пройти такую степень.
Примечание: Конфетка Fedora имеет a whatprovides
команда, которая может сделать некоторое великолепие, проверяет его.
Нет, и действительно нет никакой потребности в нем. Мы тонем в диспетчерах пакетов теперь и не нуждаемся ни в каких дополнительных на уровнях дистрибутива (rpm
, dpkg
, yum
, apt
, aptitude
, pacman
,portage
, и т.д.).
Примечание: Вот полный список диспетчеров пакетов для большей части Unixes, названного: "Список систем управления пакета программного обеспечения".
Большинство языков программирования имеет свой собственный модуль/библиотеку/диспетчеры пакетов между прочим, нет ничего по сути специального с pip
или npm
.
Кстати, руководящее программное обеспечение на уровне распределения OS'es является на самом деле passe способом сделать так. Смотрите на инструменты такой как rvm
, pyenv
, virtualenv
, virtualenvwrapper
, perlbrew
, Renv
(R), и т.д....
Я описал ответы экстенсивно на этом сайте об этих инструментах, не стесняются проверять мой задний каталог ответов.
OP задал следующий последующий вопрос в комментариях.
Я использую зернышко и npm регулярно, побеждаю почти исключительно с virtualenv. Иногда luarocks, также. Вопрос не так об их существовании. Я больше задаюсь вопросом, извлек ли дистрибутив специалисты по обслуживанию выгоду из существующих, предварительно упакованных библиотек программного обеспечения на языке определенному repos.
На который я ответил:
Я сказал бы, вероятно, не к той точке. Как Вы видите из моего ответа выше, уже существует много инвестиций в эти альтернативы и добавление Ленга. определенный просто сделал бы это более сложным, чем это уже для небольшого позитивного аспекта с точки зрения специалистов по обслуживанию пакета. Я подозреваю, что Вы спрашиваете этот b/c от своей перспективы, для дистрибутива казалось бы легче просто насладиться существующей ранее библиотекой пакетов перед сборкой, однако это затем потребует, чтобы дистрибутив насладился множеством библиотек языков.
Таким образом, Вы принялись бы за решение проблемы на уровне, где существует несоответствие импеданса между уровнем, что дистрибутив должен сохраняться, по сравнению с уровнем, на котором могут обеспечить предварительно созданные пакеты/библиотеки для данного языка.
Возможно, здесь существует своего рода скрытая проблема, поскольку модули для языков как js, Python и lua могут включать compenents, который должен быть скомпилирован, но ни один из них не действительно скомпилированный язык 1
Эти языки используют интерпретаторы, которые были скомпилированы от собственного C/C++, и они могут также использовать модули с частями, записанными в C/C++, так как те части будут:
Неизбежно будьте более эффективными.
Предоставьте доступ к собственным библиотекам C/C++. Если Вы хотите использовать, например, openGL, POSIX определенный материал, SSL, шифрование обычно, GUI освобождает (gtk, QT), и очень много других вещей в рубине, lua, и. al. это - абсолютно требование.
Так, при использовании диспетчера пакетов языка он может закончить тем, что загрузил собственный код, который является частью данного модуля, затем он должен скомпилировать это в системе. Это - мятежник общая предпосылка диспетчера пакетов дистрибутива, который является, что она просто загружает предварительно скомпилированные двоичные файлы.
Это (прежде всего), почему дистрибутивы также пакет предварительно скомпилировали формы популярных модулей для языков чьи интерпретаторы они также предварительный пакет. Это - функция, так как это означает, что Вы не должны компилировать их в своей системе. Если вместо этого Вы хотите создать модули из источника с помощью диспетчера пакетов языка, Вы всегда свободны сделать это!
1. "О, но Python или независимо от того, что может быть скомпилировано в байт-код", и т.д.: код байта все еще не является исполняемым файлом. Код байта является промежуточным шагом, используемым большинством интерпретаторов включая Java, жемчуг, Python, и т.д., и предназначается, чтобы быть портативным - значение, что он не должен быть перекомпилирован на различных платформах - но он требует специального интерпретатора, чтобы выполняться, и тот интерпретатор действительно должен был быть скомпилированной платформой конкретно.
-dev
пакеты для начальной загрузки. Все хорошо с этим, которое является, почему я часто предпочитаю поставщиков программного блока языка. Однако мне иногда не разрешают такую расточительность, и я понимаю что многие (даже: большинство), люди, учитывая выбор, предпочтут просто загружать предварительные скомпилированные версии. Дистрибутивы предоставляют услугу сверху того, что делают поставщики программного блока языка. Почему устраняют это???
– goldilocks
27.01.2014, 12:12
Чтобы ответить на ваш главный вопрос ( Есть ли попытка [...]? ):
Удивительно, да. Хотя и не относится к языкам или инструментам, которые вы упоминаете.
В течение многих лет (по крайней мере, 15) — задолго до того, как у Python появилась стабильная, принятая система упаковки, и задолго до того, как Node стал мерцать в чьих-либо глазах — операционная система FreeBSD включала систему, известную как «BSDPAN», которая обертывает упаковочную систему CPAN Perl.
Идея состоит в том, что если вы устанавливаете модуль Perl с помощью стандартных инструментов CPAN, вы можете впоследствии манипулировать установленным пакетом с помощью стандартных инструментов упаковки FreeBSD. И, в какой-то степени, наоборот.
Даже когда я принимал активное участие в сообществе Портов FreeBSD (опять же, возвращаясь > 15 лет назад), я никогда не считал BSDPAN очень масштабируемым или поддерживаемым решением. Я не уверен, что он все еще активно поддерживается сегодня (хотя быстрый Google предполагает, что это так).
В современном миретакое начинание имело бы еще большую глупость из-за распространения специфических для языка инструментов установки ... и все причины, упомянутые другими комментаторами.
Лично я предпочитаю оставлять в покое установленные в системе версии различных языков программирования, не устанавливать их через общесистемный менеджер пакетов, а поддерживать частные, полностью независимые установки с помощью таких инструментов, как rbenv, pyenv, plenv, nodenv и т. Д. В этом случае они никоим образом не могут мешать чему-либо, установленному системой (или общесистемным менеджером пакетов).