Summary: | what about virtual pkg names compatible with Fedora? | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Ivan Zakharyaschev <imz> |
Component: | rpm-build-perl | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P3 | CC: | at, crux, ldv, viy |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Ivan Zakharyaschev
2015-01-28 17:51:27 MSK
src.rpm можно конвертировать автоматически, и после пересборки у бинарного пакета зависимости будут в соответствии с дистрибутивом. Я вообще не в курсе, есть ли, какое-то обоснование, чем наш формал perl-зависимостей лучше их. А если они дают одинаковые возможности, то можно было бы и не устраивать несовместимость просто так.
(В ответ на комментарий №1)
> src.rpm можно конвертировать автоматически, и после пересборки у бинарного
> пакета зависимости будут в соответствии с дистрибутивом.
Да, это хорошо. Каким инструментом конвертировать?
Но это скорее подходит разработчику, который в курсе всей этой кухни. (Ещё и напрашивается запрос на помещение такого пакета в autoimports. Но я не уверен, что nix есть в репозиториях Fedora; может быть, есть только пакеты от создателя.)
А пользователь, у которого был бы шанс просто поставить чужой .rpm от upstream, оказывается застопорен без помощи разработчиков.
(По мелочи виртуальные provides для совместимости добавлялись в пакеты, например, в cups для установки сторонних драйверов от Xerox в виде rpm.)
не хуже и чуть может лучше (поддержка require a.pl), и исторически сложился. беда с двойными Provides: та, что индексы rpm не резиновые и забивать их лишним чревато тормозами. nix я мотрел, там надо руками допилить, у меня пока руки не дойдут. конвертер - надо установить /usr/bin/srpmconvert-fc и пакет distromap-fedora-rawhide-altlinux-sisyphus положить тарбол в SOURCES и запустить /usr/bin/srpmconvert-fc -i nix.spec (В ответ на комментарий №3) > не хуже и чуть может лучше (поддержка require a.pl), и исторически сложился. То, что не хуже, я и не сомневался. (Но может, в Fedora изобрели то же самое по возможностям.) > беда с двойными Provides: та, что индексы rpm не резиновые и забивать их лишним > чревато тормозами. Ну есть и радикальное решение: те, которые совпадают по смыслу с Fedora, заменить на fedorовские. сломается совместимость при обновлениях :( тоже не годится. (In reply to comment #5) > сломается совместимость при обновлениях :( тоже не годится. Переезд на set-versions пережили ведь. Хотя там несколько другое соотношение частей, которые ломаются было: тогда чтобы поставить новый пакет, приходилось обновлять все зависимости. Но в принципе новый пакет с библиотекой удовлетворял старые зависимости (старых пакетов). При гипотетической замене названий perl-provides новый пакет не будет удовлетворять зависимости старых пакетов. Да это вроде не так и страшно: т.е. нельзя будет, скажем, спокойно поставить модуль из Sisyphus в branch, но это не обещано, а важные обновления модулей для бранчей собираются по старой схеме. (Я просто рассуждаю гипотетически, чтобы лучше понять, как это могло бы сработать, но не утверждаю, что это нужно делать.) |