LINUX.ORG.RU

Ответ на: комментарий от Obezyan

Зачем в 23 году есть клей, если можно жевать обои?

Я не про питонский virtualenv конкретно, я про эту функциональность в каждом ПМ. В зюзе она на снапшотах ФС, что веселит меня неимоверно.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

В Сюзи Snapper управляет снимками (snapshots) ОС и использует их для восстановления/отката к предыдущему зафиксированному состоянию в случае если умудрились поломать систему.

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

Obezyan
()
Ответ на: комментарий от Obezyan

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

Правильно, я тебе про костыль, который они нагородили, чтобы имитировать virtualenvs: делать снапшот системы на уровне ФС, ставить пакеты в отдельный subvolume и имитировать таким образом virtualenvs здорового человека. Но ты ж не разбираешься, с чем споришь, просто выдаешь ассоциативный ряд на знакомые слова, ещё и anacond’у приплел зачем-то.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от papin-aziat

Я читаю, вывод всегда очень ясный у DNF.

По сравнению с зиппером, вывод днф - невнятный бубнеж.

utanho ★★★★★
()
Ответ на: комментарий от t184256

Правильно, я тебе про костыль, который они нагородили, чтобы имитировать virtualenvs: делать снапшот системы на уровне ФС, ставить пакеты в отдельный subvolume и имитировать таким образом virtualenvs здорового человека.

Я ж говорю, поток сознания.

  1. Snapper в openSuse использует стандартные возможности снимков в btrfs. Это буквально утилита создания и управления снимков (подтомов-subvolumes) на уровне ФС. Никакие пакеты туда не ставятся.

  2. Virtualenvs - утилита для управления окружением в python, позволяет иметь разные версии пакетов в разных проектах. Вообще ничего не знает о файловой системе.

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

Obezyan
()
Ответ на: комментарий от etwrq

yast, емнип норм хотя и медленнее dpkg/apt/yum/dnf

Хрестоматийное сравнение теплого с мягким.

utanho ★★★★★
()
Ответ на: комментарий от Obezyan

Не получается у нас разговора, ваши посты для меня как поток сознания.

Никсосианцы на редкость упороты. Хуже веганов.

utanho ★★★★★
()
Ответ на: комментарий от her_s_gory

А что так можно было ?

Ну конечно.

Меня от сюси оттолкнула исключительно их иррациональная тяга к кутям. Так бы сидел и сейчас.

utanho ★★★★★
()
Последнее исправление: utanho (всего исправлений: 2)
Ответ на: комментарий от einhander

Ошибка выжившего, если ты это не встречал значит этого нет, да?

За ~20 лет такого не было, предлагаете подождать еще 20? Или все-таки подкрепите свое мнение реальным примером на Suse чтобы оно выглядело не так жидко?

Obezyan
()
Ответ на: комментарий от utanho

Никсосианцы на редкость упороты. Хуже веганов.

Я не очень хорошо знаю все эти современные гендеры. Это те кто радуются что могут воспроизводить состояние системы, но при этом изменяемые сущности типа баз данных все равно нужно бекапить отдельно? Или что-то другое?

Obezyan
()
Ответ на: комментарий от t184256

ставить пакеты в отдельный subvolume и имитировать таким образом virtualenvs здорового человека

сам придумал, сам обиделся

kott ★★★★★
()
Ответ на: комментарий от Obezyan

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

einhander ★★★★★
()
Ответ на: комментарий от einhander

Были конфликты уровня A и B хотят разные версии C, но установщик вставал на паузу с вариантами ответов что с этим можно сделать и ждал пока не укажешь явно как поступить. Причем делалается эта проверка ДО начала скачивания всех пакетов и их установки.

Поэтому тут не в ментейнерах дело, а в нормальном менеджере пакетов zypper в котором этот момент детально продуман.

Obezyan
()
Ответ на: комментарий от utanho

Я это на десерт оставил, ну да ладно. Они ее 16 лет полировали. И вишенка на торте, она умеет в deb :)

Obezyan
()
Ответ на: комментарий от Obezyan

ну не так всё волшебно, можно сделать кривой пакет и только уже перед накаткой rpm скажет, что файлы будут затёрты и libsolve это никак заранее не увидит

kott ★★★★★
()
Ответ на: комментарий от kott

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

Obezyan
()
Ответ на: комментарий от t184256

Сам приплел snapper, сам разъяснил, что это другое.

Snapper в Suse и занимается созданием снапшотов которые вы путаете с virtualenv. Вы сами писали о

Зюзевцы — интересные ребята, так стараются изобрести NixOS, готовы снапшотами доверху обмазаться. Снапшот / на каждый virtualenv уже был, будет даже интересно посмотреть, какие новые глупости они заготовили.

У вас контузия от NixOS походу. В Suse никто не собирался и не собирается переизобретать «нинужное нинужно», не переживайте.

Держи конфетку.

Лучше банан, а то предыдущий я отдал.

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)
Ответ на: комментарий от kott

Там же прямо в выводе написано:

The reason for that is that old lv2-devel contains symlinks such as

/usr/include/lv2/ui -> ../../lib64/lv2/ui.lv2

while the new lv2-devel has them as directories with content inside:

/usr/include/lv2/ui
/usr/include/lv2/ui/ui.h

This is not supported by libzypp/libsolv/rpm.

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

А в комментах разрабы этого пакета как раз и обсуждают что они поменяли структуру и поведение установщика стало для них неожиданностью. Они хотят чтобы обновление шло без этой ошибки и пользователи не делали двухходовку с удалением старой и последующей установкой новой версии пакета.

Obezyan
()
Ответ на: комментарий от Obezyan

Это как раз таки криво собранный пакет lv2-devel

и какой из пакетов в данном случае кривой, старый или новый, или оба?

и в чём, собственно, кривизна?

Лечится это удалением текущей версии lv2-devel и затем установкой новой, а не прямым обновлением со старой версии на новую.

может ты расскажешь, как пофиксить, а то баг так и висит

kott ★★★★★
()
Ответ на: комментарий от kott

и какой из пакетов в данном случае кривой, старый или новый, или оба?

новый

и в чём, собственно, кривизна?

заменил символическую ссылку - папкой с файлами.

может ты расскажешь, как пофиксить, а то баг так и висит

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

А так они сделали абсолютно новую структуру пакета на что им установщик резонно сообщил что что они вместо теплого мягкое суют. Хочешь использовать rpm для распространения своей программы - соблюдай его требования.

Obezyan
()
Ответ на: комментарий от Obezyan

заменил символическую ссылку - папкой с файлами.

так выглядит новая версия lv2 по задумке автора, и во-вторых - ничего кривого в этом нет

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

ни хрена непонятно и кто «они»?

Хочешь использовать rpm для распространения своей программы - соблюдай его требования.

что за требование в данном случае?

сам же цитируешь:

The reason for that is that old lv2-devel contains symlinks such as

/usr/include/lv2/ui -> ../../lib64/lv2/ui.lv2

while the new lv2-devel has them as directories with content inside:

/usr/include/lv2/ui
/usr/include/lv2/ui/ui.h

This is not supported by libzypp/libsolv/rpm.

This is not supported by libzypp/libsolv/rpm.

всё, поменялась структура пакета - нешмогла, ой

kott ★★★★★
()
Ответ на: комментарий от kott

так выглядит новая версия lv2 по задумке автора, и во-вторых - ничего кривого в этом нет

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

ни хрена непонятно и кто «они»?

Т.к. авторы этой библиотеки не распространяют сами в rpm, то «они» это - вы.

всё, поменялась структура пакета - нешмогла, ой

Константин, вы, как один из мейнтейнеров этого пакета для openSuse могли бы посмотреть на то как это решили в других дистрибутивах, например, вот тут видно ту же lv2-devel v1.18.10 у которой:

* Sun Dec 11 2022 wally <wally>
  - fix symlink <-> directory conflicts with %pretrans scriptlet

для Mageia Linux, а вот тут видно что этот же метод применялся для исправления предыдущей версии библиотеки в Fedora:

Fri Sep 23 2022 Mamoru TASAKA <mtasaka@fedoraproject.org> - 1.18.8-3
  - Remove all symlinks in previous -devel subpackage in %pre_trans
    to ensure update transaction (#2123422)

RPM дает вам и возможность использовать скриптлеты и триггеры, ваш коллега решил эту проблему с помощью %pretrans без малого год назад в Mageia. Что вам мешает?

Я не мейнтенер пакетов, поэтому подхожу к вопросу как системный архитектор. Найти и разобраться в вопросе у меня заняло 10 минут времени. Если вас по религиозным убеждениям не устраивает использование %pretrans (хотя, это ж не богомерзкий %ghost) - я вас пойму.

Obezyan
()
Ответ на: комментарий от Obezyan

RPM дает вам и возможность использовать скриптлеты и триггеры, ваш коллега решил эту проблему с помощью %pretrans без малого год назад в Mageia. Что вам мешает?

а если почитать?

Not on the libzypp level. The file conflict check runs before any changes are made to the system. The check can not know whether there will be some script running to fix the issue before the package is extracted or not.
kott ★★★★★
()

Хватит уже искать идеальный Линукс – нет его. Все Линуксы одинаковые плюс-минус. И среди других ОС тоже нет счастья – у каждой свои проблемы. Займитесь полезным чем-нибудь.

MoldAndLimeHoney
()
Ответ на: комментарий от HerbertHoover

это интересней

sudo ls -l /var/log/YaST2/y2start.log
-rw-r--r-- 1 root root 3299 апр  7  2016 /var/log/YaST2/y2start.log
kott ★★★★★
()
Ответ на: комментарий от einhander

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

rupert ★★★★★
()
Ответ на: комментарий от utanho

Да там вообще непонятно чему они радуются. Они неадекватны.

Вполне адекватны, в своём манямирке. У них там своя логика, свои печали и радости.

Ну, типа, как в тюремной тусовке вы предложите, в качестве решения проблемы, пойти и поработать. Над вами так смеяться будут!

tiinn ★★★★★
()
Ответ на: комментарий от Obezyan

Ты про зиппер, к которому вопросов нет, кроме скорости работы и про зависимости. Я же говорю про дефект в логике работы нижележащего rpm. Apt, apt-get, aptitude тоже скажет что в зависимостях непорядок до скачивания. Только вот уже при установке rpm скажет - ой тут файлик надо заменить у другого пакета, ок же?

einhander ★★★★★
()
Ответ на: комментарий от kott

а если почитать?

а если подумать?

  1. Фабиан пишет о том что можно решить с помощью %pre или %pretrans (т.е. средствами rpm, о чем я и писал), но он не знает как сделать проверку успешной на уровне libzypp.

  2. Ему отвечает Майкл о том что проверка файлов выполняется не на уровне libzypp, а до него, т.к. проверку осуществляет libsolv.

Если вы внимательно перечитаете, то поймете что ваши коллеги как раз и подтверждают что фиксить нужно на уровне rpm через скриптлеты и других вариантов особо и нет. К таким же выводам пришли ваши коллеги из других дистрибутивов и решили эту проблему. Я привел 2 рабочих примера. Что вам мешает осознать это?

Obezyan
()
Ответ на: комментарий от Obezyan

переведи пожалуйста вот эти два поста:

(In reply to Fabian Vogt from comment #1)
> While it is possible to use a %pre or %pretrans script to perform the
> symlink -> directory conversion, I'm not aware of a way to make the libzypp
> file conflicts check happy. Any idea?

Not on the libzypp level. The file conflict check runs before any changes are made to the system. The check can not know whether there will be some script running to fix the issue before the package is extracted or not.

The actual check however is performed by libsolv. Michael(mls) would know if there is a way for a package to tell the issue should not be reported.
Not really. You could %ghost one of the files but that's gonna be quite ugly. That's currently the only way I see in the libsolv code.
kott ★★★★★
()
Ответ на: комментарий от Obezyan

К таким же выводам пришли ваши коллеги из других дистрибутивов и решили эту проблему. Я привел 2 рабочих примера. Что вам мешает осознать это?

где и когда отрабатывает %pretrans? когда и как проверяет файлы на конфликты libsolv?

kott ★★★★★
()
Ответ на: комментарий от kott

вообще это нечто…
ты мне пытаешься сказать, что если всунуть %pretrans с удалением симлинков, то zypper схавает установку, так?

kott ★★★★★
()
Ответ на: комментарий от einhander

Я же говорю про дефект в логике работы нижележащего rpm.

Вы говорите о дефекте своего понимания. Для простоты, представьте, что внутри RPM все лежит внутри одного каталога и подпапки этого каталога раскидываются по системе с помощью команд скриптлетов, прямо cp что куда. RPM последовательно выполняет команды скаченного файла и если видит что такой файл есть - предупреждает. Если написать в скриптлете rm этому файлу то ругаться не будет, нет файла нет проблем.

Т.е. rpm не проверяет содержимое скриптлетов до скачивания т.к. все команды которые меняют находятся в скриптлетах которые становятся доступны ПОСЛЕ скачивания пакета.

В deb тоже есть скриптлеты и если в них будет перетирание то никто из перечисленных вами пакетных менеджеров не скажет о проблеме ДО скачивания deb пакета также как и rpm.

Apt, apt-get, aptitude тоже скажет что в зависимостях непорядок до скачивания.

А вот именно зависимости проверяют и rpm и все выше вами перечисленное без проблем.

Вы путаете теплое с мягким. Зависимости проверяются ДО скачивания. Перетирание файлов описанное в скриптлетах проверяются ПОСЛЕ скачивания.

Obezyan
()
Ответ на: комментарий от kott

ты мне пытаешься сказать, что если всунуть %pretrans с удалением симлинков, то zypper схавает установку, так?

Я пытаюсь вам сказать что решение этой проблемы находится за 10 минут и уже решено в двух дистрибутивах. Вместо того чтобы посмотреть как решено там или связаться с ментейнерами в тех дистрибутивах для решения вопроса вы продолжаете юлить и спорить на форуме старательно игнорируя факт двух rpm которые ставят эту библиотеку без ошибок.

Obezyan
()
Ответ на: комментарий от Obezyan

это решение не работает в данном случае, об этом изначально говорит Michael Schröder, один из авторов libsolv

если ты не веришь, могу выдать rpm-ку собранную c %pretrans, rpm -U её поставит, zypper - нет

kott ★★★★★
()
Ответ на: комментарий от kott

переведи пожалуйста вот эти два поста

Я их и перевел выше. Ну давайте еще раз, но это - последний.

(В ответ на сообщение #1 от Fabian Vogt)
Можно использовать %pre or %pretrans скрипты для преобразования символических ссылок в папки, но я не уверен каким способом заставить проходить проверку файлов в libzypp. Идеи?

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

Реальную проверку осуществляет libsolv. Может Michael(mls) знает есть ли способ указать в пакете что "ошибка" не должна сообщаться.

Разве я не об этом же пишу? Подумайте.

Obezyan
()
Ответ на: комментарий от Obezyan

вот откуда это?

Проверка файлов не осуществляется на уровне libzypp
kott ★★★★★
()
Ответ на: комментарий от Obezyan

Внезапно зависимости проверяются и после скачивания файлов иначе dpkg или rpm работать не будут. При этом ПМ ставит группы пакетов определенным образом, и бывает что несколько групп подряд.

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

einhander ★★★★★
()
Ответ на: комментарий от Obezyan

Разве я не об этом же пишу? Подумайте.

До распаковки пакета проверка не может узнать есть ли какие-то скрипты которые фиксят эту проблему или нет.

и как тут поможет %pretrans, когда

До распаковки пакета проверка не может узнать есть ли какие-то скрипты которые фиксят эту проблему или нет.

kott ★★★★★
()
Ответ на: комментарий от her_s_gory

Живёт, обновляется. Есть версия LTS (Leap), есть роллинг (Tumbleweed). Я на Leap.

Я так и не понял, как там SUSE, жив, мертв? Зачем вы сюда приплели OpenSUSE.

dmitry237 ★★★
()
Последнее исправление: dmitry237 (всего исправлений: 1)
Ответ на: комментарий от Obezyan

и последний пост не перевёл:

Not really. You could %ghost one of the files but that's gonna be quite ugly. That's currently the only way I see in the libsolv code.

напоминаю, что это пишет один из авторов libsolv, отвечая на вопрос:

I'm not aware of a way to make the libzypp file conflicts check happy. Any idea?
kott ★★★★★
()
Последнее исправление: kott (всего исправлений: 1)
Ответ на: комментарий от kott

это решение не работает в данном случае, об этом изначально говорит Michael Schröder, один из авторов libsolv

Это решение работает в любом случае, и работает на уровне rpm. Про решение вопроса на уровне libsolv разговор изначально и не шел, это вы уже вкинули свои проблемы в обсуждение.

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

Obezyan
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)