Bisakah seseorang memerlukan paket "ini ATAU itu" dalam file spesifikasi RPM?


30

Apakah ada yang tahu bagaimana (atau apakah seseorang dapat) menentukan persyaratan alternatif atau serangkaian persyaratan dalam file spesifikasi, yang bertentangan dengan persyaratan tunggal?

Misalnya, ada dua paket yang tersedia, yang dinamai dengan mudah foo-bardan bar-foo. Paket saya membutuhkan salah satu dari ini tetapi tidak keduanya, dan saya tidak peduli yang mana yang hadir. Saat runtime saya menggunakan mana yang tersedia.

Jadi secara efektif saya ingin mengatakan:

Requires: foo-bar OR bar-foo

Sejauh yang saya tahu itu tidak mungkin, tapi saya pikir ada orang di sini yang tahu lebih banyak tentang RPM daripada saya, jadi mungkin ada cara untuk melakukannya.

UPDATE: Saya hanya mengontrol kemasan bar-foo, tidak foo-bar, jadi memiliki keduanya menyediakan paket virtual tidak akan berfungsi.

UPDATE: Hal yang sebenarnya saya butuhkan adalah paket virtual di dalam masing-masing paket. Katakanlah foo-bar provides eagle' andbar-foo menyediakan beagle and my package works with either (or both); but other packages require eithereagle orbeagle orfoo-bar orbar-foo`, dan sistem target dapat menginstal salah satu atau keduanya.

Saat ini saya condong untuk menyelesaikan ini dengan %preskrip yang melakukan sesuatu seperti:

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

Sementara saya cukup yakin itu akan berhasil, sepertinya ini adalah pengelakan brutal pelacakan ketergantungan RPM. Misalnya Anda tidak akan pernah melihat paket saya ketika Anda bertanya whatrequires foo-baratau whatrequires beagle.

UPDATE: Setelah dipikir-pikir, rasa sakit yang mengharuskan orang untuk menginstal di foo-barmana mereka mungkin tidak kurang dari rasa sakit menghindari manajemen ketergantungan RPM, setidaknya untuk situasi saya. Jadi, kecuali jika seseorang datang dengan cara yang benar membutuhkan "ini ATAU itu" (yang saya pikir akan menjadi fitur yang bagus di RPM pada umumnya) maka saya berencana untuk meminta hanya foo-bar dan kemudian, pada saat runtime, jika bar-footersedia saya akan memilih antara mereka sesuai dengan kriteria apa pun yang saya butuhkan.

UPDATE: ide lain, yang juga akan menipu RPM tetapi mungkin membuat keadaan menjadi benar. Mungkin saya bisa, dalam %post, bermain-main dengan basis data RPM secara langsung. Jadi %prebisa melindungi saya dari pemasangan yang tidak valid, dan %postakan berlaku surut memberitahu RPM bahwa saya memerlukan baik foo-baratau bar-fooatau keduanya, tergantung pada apa yang ada ketika saya menginstal.

Terima kasih atas sarannya!


Saya tahu ini sudah sangat tua; tetapi apakah ada solusi yang baik untuk ini? Saya membuat RPM yang memiliki java-1.6.0-openjdk di Membutuhkan: baris; tetapi dengan java7; Saya ingin mendukung java-1.7.0-openjdk juga tetapi tidak bisa menemukan cara yang baik untuk menempatkan keduanya di Membutuhkan:
vpram86

Jika Anda mengontrol pengemasan bar-foo, salah satu solusi yang mungkin adalah dengan membuatnya Provides: foo-bar, sehingga memenuhi kedua dependensi. Untuk versi rpm yang lebih baru, periksa Boolean Dependencies . Tinggal jauh dari %predan %postbagian, jangan mencoba untuk mengalahkan sistem .
forcefsck

Jawaban:


13

Ini sekarang dimungkinkan pada RPM 4.13.

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

Ini bisa sederhana seperti: Requires: (pkgA >= 3.2 or pkgB)


dari dokumen sepertinya ini tidak dapat digunakan dengan membutuhkan, hanya dependensi 'lemah' yang benar?
dsollen

Tautan kedua menunjukkan bahwa mereka dapat digunakan dengan Membutuhkan. Tautan pertama menyebutkan bahwa menggunakannya dengan cara seperti itu tidak diizinkan di Fedora, tetapi itu tidak berlaku untuk paket khusus.
carlwgeorge

9

Perilaku semacam ini sudah dilakukan oleh beberapa paket, misalnya agen pengiriman surat. Paket- paket virtual tersebut memberikan sistem Anda cara untuk mengetahui apakah kemampuan yang mereka butuhkan sudah disediakan oleh beberapa program lain.

Lihat apakah contoh paket virtual di rpm.org membantu Anda.


Terima kasih. Saya tidak berpikir paket virtual akan menyelesaikan masalah spesifik saya di sini, tetapi saya setuju mereka sangat berguna. Dalam kasus saya, saya tidak ingin memerlukan beberapa fitur umum yang disediakan oleh keduanya foo-bardan bar-foo, dan karena saya tidak mengontrol kemasan foo-barsaya tidak bisa hanya membuat mereka berdua menyediakan support-for-mypackage. Jika saya mengontrol pengemasan kedua prasyarat alternatif tersebut, maka memang paket virtual yang dibagikan akan menjadi solusi yang bagus.
Kevin Frost

5

Dua kemungkinan:

Jika bagian dari foo-bardan bar-fooAnda gunakan adalah file umum yang Anda bisa Require /path/to/file(saya pikir begitu; pengujian saya terbatas).

Situasi Anda mirip dengan dependensi opsional. Cara mereka ditangani adalah memiliki X-commonpaket dan kemudian memiliki X-foo-barpaket yang membutuhkan foo-bardan X-bar-foopaket yang membutuhkan bar-foo.


Sayangnya, tidak ada file umum. Itu akan menjadi trik keren jika ada, meskipun juga berpotensi berbahaya: beberapa versi masa depan foo-bardapat memindahkan file-nya (saya hanya mengontrol di bar-foosini). Ketergantungan opsional menarik tetapi tidak cukup apa yang saya butuhkan, karena saya benar-benar membutuhkan salah satu foo-bar atau bar-foo ; satu-satunya hal yang opsional adalah pilihannya. Terima kasih telah membalas.
Kevin Frost

Ini menyelesaikan masalah saya! Rasa GNU / Linux yang berbeda menyediakan paket virtual python3 yang berbeda: python3, python34, python35, dll. Agar paket tunggal saya dapat bekerja pada semuanya, saya dapat menggunakan sajaRequire: /usr/bin/python3
bgStack15

0

Apakah ini akan berhasil bagi Anda untuk memiliki bar-foo paket Anda menyediakan foo-bar paket virtual?

Anda kemudian dapat membuat paket burp-baz Anda membutuhkan foo-bar.


Jika melakukan hal di atas terasa skeezy (mungkin memang demikian), Anda mungkin perlu membuat dua versi RPM Anda, satu tergantung foo-bardan yang lainnya tergantung bar-foo.


Menggoda, tetapi berbahaya: sesuatu yang lain, yang benar-benar perlu foo-bar, akan hancur jika ia berpikir bar-foomemberikan sesuatu yang sebenarnya tidak. Poin penting adalah bahwa untuk paket saya, saya membutuhkan salah satu dari prasyarat tetapi tidak keduanya; tetapi paket lain mungkin benar-benar membutuhkan salah satunya saja. Dan saya tidak bisa hanya meminta keduanya, karena ada kasus nyata di mana hanya satu atau yang lain akan tersedia.
Kevin Frost

-2

Non-determinisme dalam sistem otomatis (yang merupakan manajemen ketergantungan atau mesin yang menggunakan RPM) adalah hal yang sangat buruk. Anda INGIN gagal pada situasi ini-atau-itu, karena gagal masih tidak seburuk hasil yang tidak terduga.

Untuk mengatasi masalah ini, mungkin minta paket yang Anda kontrol% memberikan token utama bahwa paket yang tidak dapat diubah juga terjadi pada% yang disediakan dan yang% bergantung pada perangkat lunak Anda lainnya; kemudian minta paket Anda% obsoletes yang tidak dapat diubah. Terutama jika sudah ada di tempat, Anda mungkin menang atas instalasi lain.

Pengemasan dan ketergantungan yang tepat dan operasi pemasangan adalah pekerjaan yang sulit. Tujuannya - instalasi yang andal, dapat diulang, dan diaudit - sangat berharga sehingga Anda dapat menyadari keuntungan dari melakukan yang benar.

Ketergantungan neraka adalah akibat dari diri sendiri. Tidak ada pengecualian


Inilah ikan yang akan saya berikan kepada Anda: Anda hanya perlu satu dari keduanya karena keduanya menyediakan beberapa file atau sumber daya. Jadi, jangan bergantung pada nama paket, hanya pada file atau sumber daya yang mereka berikan. Ya, Anda masih akan pacaran dengan non-determinisme, tetapi jika Anda benar-benar mempertimbangkan untuk mumping dengan rpmdb secara langsung, Anda sudah dengan gembira mempertimbangkan risiko yang telah dipelajari kebanyakan orang untuk dihindari. Saya harap Anda dapat menemukan solusi yang tidak menimbulkan utang teknis seperti itu.
user2066657
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.