Дистрибутив с зернышком и npm как диспетчеры пакетов?

Question

Дистрибутив с зернышком и npm как диспетчеры пакетов?

Если Вы имеете 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 версия, но я не могу найти документацию, на которой версии делают / не ведут себя этот путь.

1

lua npm pip package-management

Jeff Schaller 02.11.2015, 02:47

Ссылка

4 ответа

Языки и их диспетчеры пакетов

Perl - cpanm, cpanplus, cpanm
Ruby - драгоценные камни
Python - зернышко
Узел - npm
R - install.packages ()
список продолжается и на.....

Кстати, руководящее программное обеспечение на уровне распределения OS'es является на самом деле passe способом сделать так. Смотрите на инструменты такой как rvm, pyenv, virtualenv, virtualenvwrapper, perlbrew, Renv (R), и т.д....

Я описал ответы экстенсивно на этом сайте об этих инструментах, не стесняются проверять мой задний каталог ответов.

РЕДАКТИРОВАНИЕ № 1

OP задал следующий последующий вопрос в комментариях.

Я использую зернышко и npm регулярно, побеждаю почти исключительно с virtualenv. Иногда luarocks, также. Вопрос не так об их существовании. Я больше задаюсь вопросом, извлек ли дистрибутив специалисты по обслуживанию выгоду из существующих, предварительно упакованных библиотек программного обеспечения на языке определенному repos.

На который я ответил:

Я сказал бы, вероятно, не к той точке. Как Вы видите из моего ответа выше, уже существует много инвестиций в эти альтернативы и добавление Ленга. определенный просто сделал бы это более сложным, чем это уже для небольшого позитивного аспекта с точки зрения специалистов по обслуживанию пакета. Я подозреваю, что Вы спрашиваете этот b/c от своей перспективы, для дистрибутива казалось бы легче просто насладиться существующей ранее библиотекой пакетов перед сборкой, однако это затем потребует, чтобы дистрибутив насладился множеством библиотек языков.

Таким образом, Вы принялись бы за решение проблемы на уровне, где существует несоответствие импеданса между уровнем, что дистрибутив должен сохраняться, по сравнению с уровнем, на котором могут обеспечить предварительно созданные пакеты/библиотеки для данного языка.

является просто frontend для Усовершенствованного инструмента пакета (APT). ;) — Braiam, 27.01.2014, 01:05
я знаю это. Тот список был больше для эффекта w/o имеющий необходимость отбарабанить больше названий диспетчеров пакетов, которых я не знаю названия первое, что пришло на ум. 8-). Википедия BTW согласовывает w/меня, что это - пакет менеджер en.wikipedia.org/wiki/Package_management_system — slm♦, 27.01.2014, 01:22
, я использую зернышко и npm регулярно, побеждаю почти исключительно с virtualenv. Иногда luarocks, также. Вопрос не так об их существовании. Я больше задаюсь вопросом, извлек ли дистрибутив специалисты по обслуживанию выгоду из существующих, предварительно упакованных библиотек программного обеспечения на языке определенному repos. — kert, 27.01.2014, 01:25
@kert - Посмотрите мои обновления, сообщите мне, имеет ли это смысл. — slm♦, 27.01.2014, 01:32

goldilocks · Answer 3 · 27.01.2020, 23:15

Возможно, здесь существует своего рода скрытая проблема, поскольку модули для языков как js, Python и lua могут включать compenents, который должен быть скомпилирован, но ни один из них не действительно скомпилированный язык 1

Эти языки используют интерпретаторы, которые были скомпилированы от собственного C/C++, и они могут также использовать модули с частями, записанными в C/C++, так как те части будут:

Неизбежно будьте более эффективными.
Предоставьте доступ к собственным библиотекам C/C++. Если Вы хотите использовать, например, openGL, POSIX определенный материал, SSL, шифрование обычно, GUI освобождает (gtk, QT), и очень много других вещей в рубине, lua, и. al. это - абсолютно требование.

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

Это (прежде всего), почему дистрибутивы также пакет предварительно скомпилировали формы популярных модулей для языков чьи интерпретаторы они также предварительный пакет. Это - функция, так как это означает, что Вы не должны компилировать их в своей системе. Если вместо этого Вы хотите создать модули из источника с помощью диспетчера пакетов языка, Вы всегда свободны сделать это!

^{1. "О, но Python или независимо от того, что может быть скомпилировано в байт-код", и т.д.: код байта все еще не является исполняемым файлом. Код байта является промежуточным шагом, используемым большинством интерпретаторов включая Java, жемчуг, Python, и т.д., и предназначается, чтобы быть портативным - значение, что он не должен быть перекомпилирован на различных платформах - но он требует специального интерпретатора, чтобы выполняться, и тот интерпретатор действительно должен был быть скомпилированной платформой конкретно.}

На самом деле я использую и Linux и macos для ежедневной работы в соединении виртуальных машин и т.д. На Mac macports является моим основным диспетчером пакетов и этим вид прозрачно или использует двоичный файл или исходные пакеты, в зависимости от того, если двоичный файл доступен или нет. Также в базирующихся системах debian я делаю dget-x и создаю более новые пакеты из источника регулярно. Двоичный пакет из собственного кода может быть просмотрен как главным образом кэшируемая опция в этом смысле. И часто, когда зернышко virtualenv установка требует скомпилированной собственной библиотеки внизу, Вы сталкиваетесь со странными проблемами с основными системными библиотеками, не соответствующими и т.д. — kert, 27.01.2014, 03:13
Достаточно ярмарка. IMO, которым самая важная причина состоит в том, что поставщик программного блока дистрибутива и поставщик программного блока языка быть отличным, так, чтобы у Вас была опция любой стратегии. Некоторые люди предпочитают двоичные файлы дистрибутива даже при том, что версии имеют тенденцию быть более старыми, потому что они рассматривают их как меньшее количество азартной игры, чем локально скомпилированная.... — goldilocks, 27.01.2014, 12:00
... Если система поставщика программного блока/библиотеки языка умна, можно настроить ее для установки в отличный путь, то вид системный интерпретатор включает путь так, чтобы она предпочла локально скомпилированную версию при наличии (или наоборот). И т. д. и т. п. Вы, кажется, предполагаете, что люди ценили бы его, если бы дистрибутивы удалили эти виды опций. Если вместо этого Вы имеете в виду, сделайте поставщика программного блока языка опцией с поставщиком программного блока дистрибутива, это - в основном точно текущая ситуация + много затем бессмысленных работ по техническому обслуживанию для поставщика программного блока дистрибутива devs. — goldilocks, 27.01.2014, 12:03
"Двоичный пакет из собственного кода может быть просмотрен как главным образом кэшируемая опция"->, Который может легко занять 5-10 минут для компиляции на маленькой/занятой части сервера и требует набора -dev пакеты для начальной загрузки. Все хорошо с этим, которое является, почему я часто предпочитаю поставщиков программного блока языка. Однако мне иногда не разрешают такую расточительность, и я понимаю что многие (даже: большинство), люди, учитывая выбор, предпочтут просто загружать предварительные скомпилированные версии. Дистрибутивы предоставляют услугу сверху того, что делают поставщики программного блока языка. Почему устраняют это??? — goldilocks, 27.01.2014, 12:12

score 2 · Answer 4 · 27.01.2020, 23:15

Чтобы ответить на ваш главный вопрос ( Есть ли попытка [...]? ):

Удивительно, да. Хотя и не относится к языкам или инструментам, которые вы упоминаете.

В течение многих лет (по крайней мере, 15) — задолго до того, как у Python появилась стабильная, принятая система упаковки, и задолго до того, как Node стал мерцать в чьих-либо глазах — операционная система FreeBSD включала систему, известную как «BSDPAN», которая обертывает упаковочную систему CPAN Perl.

Идея состоит в том, что если вы устанавливаете модуль Perl с помощью стандартных инструментов CPAN, вы можете впоследствии манипулировать установленным пакетом с помощью стандартных инструментов упаковки FreeBSD. И, в какой-то степени, наоборот.

Даже когда я принимал активное участие в сообществе Портов FreeBSD (опять же, возвращаясь > 15 лет назад), я никогда не считал BSDPAN очень масштабируемым или поддерживаемым решением. Я не уверен, что он все еще активно поддерживается сегодня (хотя быстрый Google предполагает, что это так).

В современном миретакое начинание имело бы еще большую глупость из-за распространения специфических для языка инструментов установки ... и все причины, упомянутые другими комментаторами.

Лично я предпочитаю оставлять в покое установленные в системе версии различных языков программирования, не устанавливать их через общесистемный менеджер пакетов, а поддерживать частные, полностью независимые установки с помощью таких инструментов, как rbenv, pyenv, plenv, nodenv и т. Д. В этом случае они никоим образом не могут мешать чему-либо, установленному системой (или общесистемным менеджером пакетов).

Дистрибутив с зернышком и npm как диспетчеры пакетов?

Языки и их диспетчеры пакетов

РЕДАКТИРОВАНИЕ № 1

Теги

Похожие вопросы