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!
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 .Odpowiedzi:
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)źródło
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.
źródło
foo-bari drugiebar-foo, a ponieważ nie kontroluję pakowania,foo-barnie mogę po prostu zmusić ich do zapewnienia obusupport-for-mypackage. Gdybym kontrolował pakowanie obu alternatywnych wymagań, rzeczywiście udostępniony pakiet wirtualny byłby świetnym rozwiązaniem.Dwie możliwości:
Jeżeli część
foo-baribar-fooużyć jest wspólnym pliku można po prostuRequire /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 wymagafoo-bariX-bar-foopakiet, który wymagabar-foo.źródło
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 albofoo-baralbobar-foo; jedyne, co jest opcjonalne, to wybór. Dzięki za odpowiedź.Require: /usr/bin/python3Czy 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 odbar-foo.źródło
foo-bar, pękłoby, gdyby myślało, żebar-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.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
źródło