Czy można wymagać pakietu „ten LUB ten” w pliku specyfikacji RPM?


30

Czy ktoś wie, jak (lub czy można) określić alternatywne wymaganie lub zestaw wymagań w pliku specyfikacji, zamiast pojedynczego wymagania?

Załóżmy na przykład, że dostępne są dwa pakiety, wygodnie nazwane foo-bari bar-foo. Moja paczka wymaga jednego z nich, ale nie obu, i nie obchodzi mnie, który z nich jest obecny. W czasie wykonywania używam tego, co jest dostępne.

Tak skutecznie chciałbym powiedzieć:

Requires: foo-bar OR bar-foo

O ile wiem, nie jest to możliwe, ale sądzę, że są tu ludzie, którzy wiedzą o RPM o wiele więcej niż ja, więc może jest jakiś sposób, aby to zrobić.

AKTUALIZACJA: Kontroluję tylko pakowanie bar-foo, a nie foo-bar, więc udostępnienie pakietu wirtualnego nie będzie działać.

AKTUALIZACJA: Rzeczą, której tak naprawdę potrzebuję, jest wirtualny pakiet wewnątrz każdego z pakietów. Powiedz foo-bar provides eagle' andbar-foo zapewnia beagle and my package works with either (or both); but other packages require eithereagle orbeagle orfoo-bar orbar-foo`, a system docelowy może mieć zainstalowany jeden lub oba.

Obecnie skłaniam się do rozwiązania tego za pomocą %preskryptu, który robi coś takiego:

rpm -q eagle || rpm -q beagle || echo "need eagle or beagle" && /bin/false

Chociaż jestem prawie pewien, że to zadziała, wydaje się, że to brutalne obejście śledzenia zależności RPM. Na przykład nigdy nie zobaczysz mojej paczki, gdy zapytasz whatrequires foo-barlub whatrequires beagle.

AKTUALIZACJA: Z drugiej strony, ból związany z wymaganiem od ludzi instalacji w foo-barmiejscu, w którym mogą nie być, jest mniejszy niż ból związany z obchodzeniem zarządzania zależnością RPM, przynajmniej w mojej sytuacji. Tak więc, chyba że ktoś wymyśli sposób, aby właściwie wymagać „tego LUB tego” (co, moim zdaniem, byłoby świetną cechą w RPM), to planuję wymagać tylko, foo-bar a następnie, w czasie wykonywania, jeśli bar-foojest dostępny, wybiorę pomiędzy je według dowolnych kryteriów, których potrzebuję.

AKTUALIZACJA: kolejny pomysł, który również oszukuje RPM, ale może doprowadzić do właściwego stanu. Może mógłbym, bezpośrednio %post, majstrować przy bazie danych RPM. W ten sposób %premoże chronić mnie przed nieprawidłową zainstalować i %postbędzie wstecznie RPM powiedzieć, że wymagają albo foo-baralbo bar-fooalbo oba, w zależności od tego, co tam jest po zainstalowaniu.

Dzięki za sugestie!


Wiem, że to jest bardzo stare; ale czy istnieje teraz na to dobre rozwiązanie? Tworzę RPM, który ma java-1.6.0-openjdk w Wymagane: linia; ale z java7; Chciałbym również wesprzeć java-1.7.0-openjdk, ale nie mogłem znaleźć dobrego sposobu na umieszczenie jednego z tych dwóch w Wymaga:
vpram86 22.08.13

Jeśli kontrolujesz pakowanie bar-foo, jednym z możliwych rozwiązań jest jego zbudowanie Provides: foo-bar, aby spełniało obie zależności. W przypadku nowszych wersji rpm sprawdź zależności logiczne . Trzymaj się z dala od %prei %postsekcje, nie starają się pokonać system .
forcefsck

Odpowiedzi:


13

Jest to teraz możliwe od wersji RPM 4.13.

https://rpm.org/user_doc/boolean_dependencies.html

Może to być po prostu proste: Requires: (pkgA >= 3.2 or pkgB)


z dokumentu wygląda na to, że nie można ich używać z wymaganiami, tylko „słabe” zależności są poprawne?
dsollen

Drugi link pokazuje, że można ich używać z Wymaga. Pierwszy link wspomina, że ​​używanie go w ten sposób nie jest dozwolone w Fedorze, ale nie będzie miało zastosowania do niestandardowych pakietów.
carlwgeorge

9

Tego rodzaju zachowanie jest już realizowane przez kilka pakietów, na przykład agentów transportu poczty. Te wirtualne pakiety dają Twojemu systemowi możliwość sprawdzenia, czy potrzebna mu zdolność jest już zapewniona przez inny program.

Sprawdź, czy przykład pakietów wirtualnych w rpm.org ci pomaga.


Dzięki. Nie sądzę, że wirtualne pakiety rozwiążą tutaj mój konkretny problem, ale zgadzam się, że są bardzo przydatne. W moim przypadku nie chcę wymagać jakiejś wspólnej funkcji zapewnianej przez jedno foo-bari drugie bar-foo, a ponieważ nie kontroluję pakowania, foo-barnie mogę po prostu zmusić ich do zapewnienia obu support-for-mypackage. Gdybym kontrolował pakowanie obu alternatywnych wymagań, rzeczywiście udostępniony pakiet wirtualny byłby świetnym rozwiązaniem.
Kevin Frost,

5

Dwie możliwości:

Jeżeli część foo-bari bar-fooużyć jest wspólnym pliku można po prostu Require /path/to/file(ja myślę więc, moje badania był ograniczony).

Twoja sytuacja jest podobna do opcjonalnych zależności. Sposób, w jaki są obsługiwane, to mieć X-commonpakiet, a następnie mieć X-foo-barpakiet, który wymaga foo-bari X-bar-foopakiet, który wymaga bar-foo.


Niestety nie ma wspólnych plików. Byłoby to fajną sztuczką, gdyby były, choć potencjalnie niebezpieczne: niektóre przyszłe wersje foo-barmogłyby przenosić swoje pliki ( bar-footutaj kontroluję tylko ). Opcjonalne zależności są ciekawe, ale nie całkiem to, czego potrzebuję, bo naprawdę potrzebujemy albo foo-bar albo bar-foo ; jedyne, co jest opcjonalne, to wybór. Dzięki za odpowiedź.
Kevin Frost

To rozwiązało mój problem! Różne wersje GNU / Linux zapewniają różne pakiety wirtualne python3: python3, python34, python35 itp. Aby mój pojedynczy pakiet działał na wszystkich z nich, mogłem po prostu użyćRequire: /usr/bin/python3
bgStack15

0

Czy zadziała, jeśli Twój pakiet bar-foo dostarczy pakiet wirtualny foo-bar?

Następnie możesz po prostu sprawić, aby Twój pakiet burp-baz wymagał foo-bar.


Jeśli wykonanie powyższego wydaje się skeezy (prawdopodobnie tak jest), może być konieczne utworzenie dwóch wersji RPM, jednej w zależności od foo-bardrugiej, a drugiej w zależności od bar-foo.


Kuszące, ale niebezpieczne: coś innego, co naprawdę potrzebuje foo-bar, pękłoby, gdyby myślało, że bar-foozapewnia coś, czego tak naprawdę nie było. Problem polega na tym, że dla mojej paczki potrzebuję jednego z warunków wstępnych, ale nie obu; ale każdy inny pakiet może naprawdę potrzebować tylko jednego z nich. I nie mogę po prostu wymagać obu z nich, ponieważ istnieją prawdziwe przypadki, w których dostępny będzie tylko jeden lub drugi.
Kevin Frost

-2

Niedeterminizm w zautomatyzowanych systemach (którym jest zarządzanie zależnościami lub maszyny korzystające z RPM) to naprawdę zła rzecz. CHCESZ, aby zawiódł w takiej lub innej sytuacji, ponieważ niepowodzenie wciąż nie jest tak złe, jak nieoczekiwany wynik.

Aby rozwiązać problem, być może pakiet, który kontrolujesz%, podaje główne tokeny, które niezmienny pakiet zdarza się również%, i od którego zależy inne oprogramowanie%; wtedy twój pakiet% przestaje być niezmienny. Zwłaszcza jeśli jest już na miejscu, możesz wygrać z inną instalacją.

Pakowanie oraz prawidłowe operacje zależności i instalacji to trudna praca. Cel - niezawodne, powtarzalne, sprawdzalne instalacje - jest tak cenny, że możesz zdać sobie sprawę z korzyści płynących z poprawnego wykonania.

Piekło uzależnienia jest samookaleczone. Bez wyjątków


Oto ryba, którą ci dam: Potrzebujesz tylko jednego z dwóch, ponieważ oba zapewniają jakiś plik lub zasób. Tak więc, nie% zależy od nazwy pakietu, tylko od dostarczonego pliku lub zasobu. Tak, nadal będziesz zabiegał o brak determinizmu, ale jeśli tak naprawdę zastanawiasz się nad bezpośrednim pomijaniem rpmdb, już z radością rozważasz ryzyko, którego większość ludzi nauczyła się unikać. Mam nadzieję, że znajdziesz rozwiązanie, które nie spowoduje takiego długu technicznego.
user2066657,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.