А если у них инторнета даже нету? Они копируют rpm на флэшке

Зачем у всех? Вот там рядом, где дебиан.

Это, кстати, опять, кажется эта больная тема - "Доставка кода за высокий забор"

Зачем у всех? Вот там рядом, где дебиан.

И что это даст?

Это, кстати, опять, кажется эта больная тема - "Доставка кода за высокий забор"

Да, больная. Но с дебиан пакетом всё отлично работает, а вот с rpm косячно как-то

И что это даст?

Это даст возможность собирать пакеты нормально, а не собирать Ниссан на заводе Тойоты.

Это даст возможность собирать пакеты нормально, а не собирать Ниссан на заводе Тойоты.

А подробнее можно? Что именно будет "лучше"?

Почему виртауленв будет нормально создаваться после этого на центоси или редхате?

Так было раньше и было переделано потому что не всё нормально работало после установки. Кстати, сборка RPM производится на дебиане. А установка уже на редхат-бэйзед дистрах. И это так же вносит свои нюансы, именно поэтому и хочется виртуаленв не запаковывать внутрь RPM, а накатывать его уже в момент установки.

невозможно разумными силами собрать RPM на одном дистре, чтобы оно гарантировано работало на другом. сам RPM даже не стандартизирован - у каждого свой, с уникальными фишками.

невозможно разумными силами собрать RPM на одном дистре, чтобы оно гарантировано работало на другом. сам RPM даже не стандартизирован - у каждого свой, с уникальными фишками.

Тем не менее без виртуаленва всё работало.

Почему виртауленв будет нормально создаваться после этого на центоси или редхате?

Просто в силу того, что rpm создавался и отлажен на RPM-based дистрибутиве. Там половина функциональности - макросы, если что. И эти макросы (сюрприз-сюрприз!) различаются для разных дистров и платформ.

Просто в силу того, что rpm создавался и отлажен на RPM-based дистрибутиве. Там половина функциональности - макросы, если что. И эти макросы (сюрприз-сюрприз!) различаются для разных дистров и платформ.

То есть если я буду делать сборку пакета не в дебиане виртуаленв начнёт накатываться корректно?

Тем не менее без виртуаленва всё работало.

это работало в состоянии "выглядит что работает, не дышите на это". так жить нельзя)

это работало в состоянии "выглядит что работает, не дышите на это". так жить нельзя)

Нет, нормально оно работало. Просто с тех пор много воды утекло, и теперь нужно собирать виртуаленв и собирать его на целевой системе, а не на сборочной. Точнее даже и там и там приходится собирать, но перед запаковкой в RPM на билд системе собраный env очищается.

Нет, нормально оно работало. Просто с тех пор много воды утекло, и теперь нужно собирать виртуаленв и собирать его на целевой системе, а не на сборочной. Точнее даже и там и там приходится собирать, но перед запаковкой в RPM на билд системе собраный env очищается.

ну раз всё нормально, то что ж %postinst то не работает? :)

То есть если я буду делать сборку пакета не в дебиане виртуаленв начнёт накатываться корректно?

Я не берусь утверждать, что прям хоп и начнёт. Просто делюсь опытом - "вот так стопудово работает". Если считаешь это применимым - ок, считаешь неприменимым - мне-то тоже ок 😉

ну раз всё нормально, то что ж %postinst то не работает? :)

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

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

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

Я не берусь утверждать, что прям хоп и начнёт. Просто делюсь опытом - "вот так стопудово работает". Если считаешь это применимым - ок, считаешь неприменимым - мне-то тоже ок 😉

Стопудово и с дебианом работает. Но если только не запускать python3 -m virtualenv %{ENV_DIR} -p python3 в postinst

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

Так что делать с виртауленвом в постинсталле?

Так что делать с виртауленвом в постинсталле?

Забить, как и на наши рекомендации 😊

И уволиться сразу =)

И уволиться сразу =)

Твоя жизнь - твои решения. Я бы сначала попробовал объяснить, почему поставленная задача не имеет корректного решения.

Всё-таки хотелось бы отдебажить эту пробелму и понять причину почему одна и та же команда выполняется по-разному руками и из постинсталла

Всё-таки хотелось бы отдебажить эту пробелму и понять причину почему одна и та же команда выполняется по-разному руками и из постинсталла

Я бы начал с журнала аудита SELinux.

Ну и команда создания virtualenv всё же выглядит по-другому: https://media.readthedocs.org/pdf/virtualenv/stable/virtualenv.pdf

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

Да, так и есть. Всё что надо он несёт

нет. он требует доступ к pypi в post секции

нет. он требует доступ к pypi в post секции

+

а это никак не самодостаточность пакета.

Если речь о том, что нужно просто запустить последовательность команд - для этого хорошо подойдёт шелл-скрипт.

нет. он требует доступ к pypi в post секции

Это в какой строке?

Ну и команда создания virtualenv всё же выглядит по-другому: https://media.readthedocs.org/pdf/virtualenv/stable/virtualenv.pdf

А вот, кстати, командой virtualenv-3 %{ENV_DIR} похоже всё нормально создаётся и изнутри rpm. Если честно не знаю для чего юзали виртуаленв как модуль для питона что бы развернуть окружение. Это было сделано до меня.

А вот, кстати, командой virtualenv-3 %{ENV_DIR} похоже всё нормально создаётся и изнутри rpm. Если честно не знаю для чего юзали виртуаленв как модуль для питона что бы развернуть окружение. Это было сделано до меня.

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

Да, надо бы как-нить попробовать собрать приложение со всей хурмой с нуля. Но по поводу запаковки всех вилов внутрь рпм, я почти уверен в необходимости. Недавно вот джанга новая вышла и начала вытягиваться автоматом. Пришлось фиксировать версию. А если вспомнить известную историю с npm, можно представить возможные проблемы и с пипом.

Опачки... Открылась новая деталь... Я делал ls на каталоге env/bin в процессе установки пакета и все нужные файлы там были. Потом при попытке запустить приложение я увидел, что оно не пашет и сделал ls снова, и увидел, что почти всех файлов нет... При этом в постинсталле нет никаких команд, которые могли бы затирать каталог с виртуаленвом, темболее так странно и не целиком. Похоже какая-то иная магия преследует меня =(

Не, ну это какое-то издевательство!!! Удалил вообще все инструкции из постинсталла, кроме виртуаленва. И в момент запуска виртуаленва в каталоге даже больше файлов становится и их дата заменяется на свежую. Но потом внезапно всё нахер исчезает. Как так то? Почему?

Сходу даже не понятно как у гугла спросить эту хрень.

Эпичные выходные с натягиванием совы на глобус))

Главное непонятно почему пропадают не все файлы. Я бы ещё понял, если бы вообще всё удалялось, можно было бы искать где-то эту интсрукцию, но там остаётся 4 файла lrwxrwxrwx. 1 root root 9 ноя 23 17:18 python -> python3.4 -rwxr-xr-x. 1 root root 11312 ноя 23 17:18 python3.4 -rwxr-xr-x. 1 root root 2338 ноя 23 17:18 python-config -rwxr-xr-x. 1 root root 231 ноя 23 17:18 wheel

Если сделать анинсталл RPMки, а потом по новой ставить, то она не удаляет за собой большу часть енва. Но если делать rpm -iU то есть апдейт версии, то почему-то после выполнения постинсталла она херачит файлы...

В спеке никаких инструкций на тему апдейта не указано.

Если сделать анинсталл RPMки, а потом по новой ставить, то она не удаляет за собой большу часть енва. Но если делать rpm -iU то есть апдейт версии, то почему-то после выполнения постинсталла она херачит файлы...

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

И таким и будет оставлен по завершении работы. Модель "RPM - тупая запускалка скриптов" некорректна.

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

И таким и будет оставлен по завершении работы. Модель "RPM - тупая запускалка скриптов" некорректна.

Вот это и печально, кстати. Я именно так к этому и относился.

Думаю, ты сам всё понял. Философию и взгляды создателей дистрибутива невозможно переделать скриптами 😊

Да эт понятно, но что за странная философия то? И как с этим жить?

Кстати, странно, почему не удаляются все файлы тогда. Ведь в спеке у меня не описно наличие именно этих вот файлов. Есть только соседний каталог.

Как жить - описано выше. Артефакт либо самодостаточен (при этом внутри него описано всё, что используется при установке/настройке), либо тянет за собой такие же самодостаточные артефакты через "Requires:" или "BuildRequires".

То есть запускать штуку, которая создаёт дополнительные файлы в данном кейсе невозможно? Нужно либо создавать и подкладывать эти файлы заранее, либо вообще не юзать RPM?

Для полноты картины ты можешь пометить отдельный каталог как отхожее место, куда всё и вся может создавать файлы, и этот гадюшник RPM-у трогать не надо.

А какой инструкцией это можно сделать?

http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html %dir - твой друг и союзник. создаст тебе каталог, а в нём хоть игорный дом с прелестницами и марьяжём открывай.

Что-то не сработало.

И всё таки, я пропустил ответ на вопрос "почему не докер"?

И всё таки, я пропустил ответ на вопрос "почему не докер"?

так и хочется задать вопрос "почему докер?"

И все-таки хочется задать вопрос почему

так и хочется задать вопрос "почему докер?"

Как я понял, у человека есть проблема с тем, что ему нужно поставлять пакет, который бы притянул за собой нужное окружение. Средствами rpm это получается очень не просто, как мне кажется. Вроде похоже на юзкейс докера. Я не прав?

Как я понял, у человека есть проблема с тем, что ему нужно поставлять пакет, который бы притянул за собой нужное окружение. Средствами rpm это получается очень не просто, как мне кажется. Вроде похоже на юзкейс докера. Я не прав?

нет. Докер не решает все проблемы мира разом.

а RPM прекрасно решает работу с зависимостями.

Но он решает проблему доставки и фиксации окружения для кода, разве нет?

RPM ее тоже решает, но иначе.

Раз у нас есть два инструмента, которые можно использовать, то их можно и сравнить. Почему не rpm я могу предположить, вот у человека сверху не получается. А почему не докер?

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

Ну и мне казалось, что рпм решает проблемы всё-таки софта, а не окружения. То есть в нем должно быть приложение или либа, а не окружения. А других случаях вроде как не основной юзкейс, а значит можно рассматривать альтернативы

ну вообще да. Окружнием должен заниматься SCM. А тут его нет, видимо :)

Да эт понятно, но что за странная философия то? И как с этим жить?

Начинается на д, заканчивается на р и многие считают, что не нужен)

Начинается на д, заканчивается на р и многие считают, что не нужен)

С детства не люблю загадки

> не люблю загадки > работаю в ИТ

телепаты не любят загадки, это скучно

Как я понял, у человека есть проблема с тем, что ему нужно поставлять пакет, который бы притянул за собой нужное окружение. Средствами rpm это получается очень не просто, как мне кажется. Вроде похоже на юзкейс докера. Я не прав?

А докером типа просто запустить базу, всякое с npm и джангу под uwsgi?

Ну человек выше правильно написал. Приложение под докер тоже нужно готовить

Есть шанс что это не надо)

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

Чего сложного? Запихал все по разным контейнерам им дал отдельную сеть и они взаимодействуют друг с другом

И всё таки, я пропустил ответ на вопрос "почему не докер"?

Хотябы потому что решение, "разрушить до основания и собрать заново" ну такое. Вон комунисты пробовали...

так не "мультипроцессорные системы", а "монолитное винтажное гуано"

Хотябы потому что решение, "разрушить до основания и собрать заново" ну такое. Вон комунисты пробовали...

Ну переехать да, сложновато. Особеннл еслт много костылей вокруг)