Người ta có thể yêu cầu gói này HOẶC gói đó trong một tệp spec RPM không?


30

Có ai biết làm thế nào (hoặc liệu người ta có thể) chỉ định một yêu cầu thay thế hoặc tập hợp các yêu cầu trong một tệp spec, trái ngược với một yêu cầu không?

Ví dụ, giả sử có hai gói có sẵn, được đặt tên thuận tiện foo-barbar-foo. Gói của tôi yêu cầu một trong những thứ này nhưng không phải cả hai và tôi không quan tâm cái nào có mặt. Trong thời gian chạy tôi sử dụng bất cứ điều gì có sẵn.

Vì vậy, hiệu quả tôi muốn một cách để nói:

Requires: foo-bar OR bar-foo

Theo như tôi có thể nói là không thể, nhưng tôi nghĩ rằng có những người ở đây biết nhiều về RPM hơn tôi, vì vậy có lẽ có cách để làm điều đó.

CẬP NHẬT: Tôi chỉ kiểm soát việc đóng gói bar-foo, không foo-bar, vì vậy cả hai cung cấp một gói ảo sẽ không hoạt động.

CẬP NHẬT: Thứ tôi thực sự cần là một gói ảo bên trong mỗi gói. Say foo-bar provides eagle' andbar-foo cung cấp and my package works with either (or both); but other packages require eitherđại bàng orbeagle beagle orfoo-bar orbar-foo`, và hệ thống đích có thể được cài đặt hoặc cả hai.

Tôi hiện đang nghiêng về việc giải quyết vấn đề này bằng một %prekịch bản có nội dung như sau:

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

Mặc dù tôi khá chắc chắn rằng nó sẽ hoạt động, nó có vẻ như là một sự phá vỡ tàn bạo của theo dõi phụ thuộc của RPM. Chẳng hạn, bạn sẽ không bao giờ thấy gói của tôi khi bạn hỏi whatrequires foo-barhay whatrequires beagle.

CẬP NHẬT: Về suy nghĩ thứ hai, nỗi đau của việc yêu cầu mọi người cài đặt foo-barở nơi họ có thể không ít hơn nỗi đau của việc lách luật quản lý phụ thuộc RPM, ít nhất là đối với tình huống của tôi. Vì vậy, trừ khi ai đó nghĩ ra cách yêu cầu "cái này HOẶC cái kia" (mà tôi nghĩ sẽ là một tính năng tuyệt vời để có trong RPM nói chung) thì tôi dự định chỉ yêu cầu foo-barvà sau đó, khi bar-foocó sẵn, tôi sẽ chọn giữa chúng theo bất cứ tiêu chí nào tôi cần

CẬP NHẬT: một ý tưởng khác, cũng sẽ gian lận RPM nhưng có thể đưa mọi thứ vào đúng trạng thái. Có lẽ tôi có thể, %posttrực tiếp tìm hiểu cơ sở dữ liệu của RPM. Như vậy %precó thể bảo vệ tôi khỏi một hợp lệ cài đặt, và %posthồi tố sẽ nói với RPM mà tôi yêu cầu một trong hai foo-barhoặc bar-foohoặc cả hai, tùy thuộc vào những gì có khi tôi cài đặt.

Cảm ơn những lời đề nghị!


Tôi biết điều này rất cũ; Nhưng có một giải pháp tốt bây giờ cho việc này? Tôi đang thực hiện một RPM có java-1.6.0-openjdk trong Yêu cầu: dòng; nhưng với java7; Tôi cũng muốn hỗ trợ java-1.7.0-openjdk nhưng không thể tìm ra một cách hay để đưa một trong hai thứ đó vào Yêu cầu:
vpram86

Nếu bạn kiểm soát bao bì của bar-foo, một giải pháp khả thi là xây dựng nó với Provides: foo-bar, để nó thỏa mãn cả hai phụ thuộc. Đối với các phiên bản vòng / phút mới hơn, hãy kiểm tra Phụ thuộc Boolean . Tránh xa %pre%postcác phần, đừng cố gắng đánh bại hệ thống .
Forcefsck 8/2/2016

Câu trả lời:


13

Điều này hiện có thể kể từ RPM 4.13.

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

Nó có thể chỉ đơn giản như: Requires: (pkgA >= 3.2 or pkgB)


từ tài liệu có vẻ như những thứ này không thể được sử dụng với yêu cầu, chỉ phụ thuộc 'yếu' mới đúng?
DSollen

Liên kết thứ hai cho thấy rằng chúng có thể được sử dụng với Yêu cầu. Liên kết đầu tiên đề cập đến việc sử dụng nó theo cách đó không được phép trong Fedora, nhưng điều đó sẽ không áp dụng cho các gói tùy chỉnh.
carlwgeorge

9

Loại hành vi này đã được thực hiện bởi một số gói, ví dụ như các đại lý vận chuyển thư. Các gói ảo đó cung cấp cho hệ thống của bạn một cách để biết liệu một khả năng mà chúng cần đã được cung cấp bởi một số chương trình khác.

Xem nếu ví dụ gói ảo trong rpm.org giúp bạn.


Cảm ơn. Tôi không nghĩ các gói ảo sẽ giải quyết vấn đề cụ thể của tôi ở đây, nhưng tôi đồng ý rằng chúng rất hữu ích. Trong trường hợp của tôi, tôi không muốn yêu cầu một số tính năng phổ biến cung cấp bởi cả hai foo-barbar-foo, và kể từ khi tôi không kiểm soát bao bì của foo-bartôi không thể chỉ làm cho họ cả hai cung cấp support-for-mypackage. Nếu tôi kiểm soát việc đóng gói cả hai điều kiện tiên quyết thay thế thì thực sự một gói ảo được chia sẻ sẽ là một giải pháp tuyệt vời.
Kevin Frost

5

Hai khả năng:

Nếu một phần foo-barbar-foobạn sử dụng là một tệp chung bạn có thể chỉ Require /path/to/file(tôi nghĩ vậy; thử nghiệm của tôi bị hạn chế).

Tình hình của bạn tương tự như phụ thuộc tùy chọn. Cách họ được xử lý là có một X-commongói và sau đó có một X-foo-bargói yêu cầu foo-barvà một X-bar-foogói yêu cầu bar-foo.


Không có tập tin phổ biến, không may. Đó sẽ là một mẹo hay nếu có, mặc dù cũng có khả năng nguy hiểm: một số phiên bản trong tương lai foo-barcó thể di chuyển các tệp của nó (tôi chỉ kiểm soát bar-fooở đây). Phụ thuộc tùy chọn là thú vị nhưng không hoàn toàn những gì tôi cần, vì tôi thực sự cần một trong hai foo-bar hoặc bar-foo ; điều duy nhất tùy chọn là sự lựa chọn trong đó. Cảm ơn vì đã trả lời.
Kevin Frost

Điều này đã giải quyết vấn đề của tôi! Các hương vị GNU / Linux khác nhau cung cấp các gói ảo python3 khác nhau: python3, python34, python35, v.v. Để gói duy nhất của tôi hoạt động trên tất cả chúng, tôi chỉ có thể sử dụngRequire: /usr/bin/python3
bgStack15

0

Nó có hoạt động để bạn có gói thanh-foo của bạn cung cấp gói foo-bar ảo không?

Sau đó, bạn có thể làm cho gói burp-baz của bạn yêu cầu foo-bar.


Nếu thực hiện những điều trên cảm thấy chóng mặt (có lẽ là vậy), bạn có thể cần phải tạo hai phiên bản RPM của mình, một phiên bản tùy thuộc foo-barvà phiên bản còn lại tùy thuộc vào bar-foo.


Hấp dẫn, nhưng nguy hiểm: một thứ khác, thứ thực sự cần foo-bar, sau đó sẽ bị phá vỡ nếu nó nghĩ rằng nó bar-foođang cung cấp thứ gì đó mà nó thực sự không có. Điểm gắn bó là cho tôi gói Tôi cần một trong hai của điều kiện tiên quyết nhưng không phải cả hai; nhưng bất kỳ gói nào khác có thể thực sự cần chỉ một trong số chúng. Và tôi không thể chỉ yêu cầu cả hai, vì có những trường hợp thực tế chỉ có cái này hoặc cái kia sẽ có sẵn.
Kevin Frost

-2

Không xác định trong các hệ thống tự động (là quản lý phụ thuộc hoặc máy sử dụng RPM) là một điều thực sự tồi tệ. Bạn muốn nó thất bại trong tình huống này hay điều đó, vì thất bại vẫn không tệ như một kết quả bất ngờ.

Để giải quyết vấn đề, có thể có gói bạn DO kiểm soát% cung cấp mã thông báo chính mà gói không thay đổi cũng xảy ra với% cung cấp và phần mềm khác mà% của bạn phụ thuộc; sau đó có gói% của bạn đã lỗi thời. Đặc biệt là nếu nó đã sẵn sàng, bạn có thể giúp nó chiến thắng các cài đặt khác.

Đóng gói và phụ thuộc thích hợp và hoạt động cài đặt là công việc khó khăn. Mục tiêu - cài đặt đáng tin cậy, có thể lặp lại, có thể kiểm tra được - rất có giá trị để bạn có thể nhận ra lợi ích của việc làm cho đúng.

Phụ thuộc địa ngục là tự gây ra. Không có ngoại lệ


Đây là con cá tôi sẽ đưa cho bạn: Bạn chỉ cần một trong hai vì cả hai đều cung cấp một số tệp hoặc tài nguyên. Vì vậy, đừng% phụ thuộc vào tên của gói, chỉ dựa vào tệp hoặc tài nguyên họ cung cấp. Có, bạn vẫn sẽ tán tỉnh chủ nghĩa không xác định, nhưng nếu bạn thực sự đang xem xét việc miết trực tiếp với rpmdb, thì bạn đã vui vẻ xem xét các rủi ro mà hầu hết mọi người đã học để tránh. Tôi hy vọng bạn có thể tìm thấy một giải pháp không phát sinh nợ kỹ thuật như vậy.
dùng2066657
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.