আরপিএম স্পেক ফাইলটিতে কারও কি "এই বা সেই" প্যাকেজটির প্রয়োজন?


30

কেউ কি জানেন যে কীভাবে (বা এক পারে) একটি একক প্রয়োজনের বিপরীতে কোনও বিকল্প ফাইল বা একটি নির্দিষ্ট ফাইলে প্রয়োজনীয়তার সেট নির্দিষ্ট করতে পারে?

উদাহরণস্বরূপ, বলুন এখানে দুটি প্যাকেজ উপলব্ধ রয়েছে, সুবিধামত নামকরণ করা হয়েছে foo-barএবং bar-foo। আমার প্যাকেজটির মধ্যে একটির প্রয়োজন তবে উভয়ই নয় এবং কোনটি উপস্থিত তা আমি পাত্তা দিই না। রানটাইম এ আমি যা ব্যবহার করি তা উপলব্ধ।

এত কার্যকরভাবে আমি বলার উপায় চাই:

Requires: foo-bar OR bar-foo

যতদূর আমি বলতে পারি যে এটি সম্ভব নয়, তবে আমি অনুমান করেছি যে এখানে এমন লোক আছেন যারা আমার চেয়ে আরপিএম সম্পর্কে আরও অনেক কিছু জানেন, তাই সম্ভবত এটি করার একটি উপায় রয়েছে।

আপডেট: আমি কেবল প্যাকেজিং নিয়ন্ত্রণ করি bar-fooনা foo-bar, তাই ভার্চুয়াল প্যাকেজ সরবরাহ করার ফলে উভয়ই কাজ করবে না।

আপডেট: আমার আসলে যে জিনিসটি প্রয়োজন তা হ'ল প্রতিটি প্যাকেজের অভ্যন্তরে ভার্চুয়াল প্যাকেজ। বলুন foo-bar provides eagle' andবার- ফু বিগল ag and my package works with either (or both); but other packages require eitherগল orবিগল ফু or-বার orবার-ফু সরবরাহ করে এবং লক্ষ্য সিস্টেমে দুটি বা উভয়ই ইনস্টল থাকতে পারে।

আমি বর্তমানে এমন একটি %preস্ক্রিপ্ট দিয়ে এর সমাধানের দিকে ঝুঁকছি যা এরকম কিছু করে:

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

যদিও আমি নিশ্চিত যে এটি কার্যকর হবে, এটি RPM এর নির্ভরশীলতা ট্র্যাকিংয়ের নৃশংস পরিস্থিতিতে বলে মনে হচ্ছে। উদাহরণস্বরূপ আপনি জিজ্ঞাসা করলে whatrequires foo-barবা কখনই আমার প্যাকেজটি দেখতে পাবেন না whatrequires beagle

আপডেট: দ্বিতীয় ভাবাতে, লোকেরা foo-barযেখানে ইনস্টল করতে হবে তাদের প্রয়োজনীয় বেদনা কমপক্ষে আমার পরিস্থিতির জন্য, আরপিএম নির্ভরতা পরিচালনার অবসন্ন হওয়ার বেদনার চেয়ে কম নয়। সুতরাং যদি না কেউ সঠিকভাবে "এই ওআর" প্রয়োজন হয় (যা আমি মনে করি সাধারণত আরপিএমের মধ্যে থাকা একটি দুর্দান্ত বৈশিষ্ট্য হবে) প্রয়োজন হয় তবে আমি পরিকল্পনা করি কেবলমাত্র foo-bar এবং তারপরে, রানটাইম এ, যদি bar-fooপাওয়া যায় তবে আমি তাদের মধ্যে বেছে নেব আমার যা প্রয়োজন মানদণ্ড অনুসারে সেগুলি।

আপডেট: আর একটি ধারণা, যা আরপিএমকে প্রতারণা করবে কিন্তু জিনিসগুলি সঠিক অবস্থায় পেতে পারে। সম্ভবত আমি %postসরাসরি আরপিএম এর ডাটাবেসটি দিয়ে বেড়াতে পারি। এভাবে %preএকটি থেকে আমাকে রক্ষা করতে পারে অবৈধ ইনস্টল করুন, এবং %postব্যাপকভাবে আরপিএম বলুন যে আমি হয় করতে হবে foo-barবা bar-fooঅথবা উভয়, কি উপর নির্ভর করে সেখানে যখন আমি ইনস্টল করুন।

পরামর্শের জন্য ধন্যবাদ!


আমি জানি এটি খুব পুরানো; তবে এর জন্য এখন কি কোনও ভাল সমাধান পাওয়া যায়? আমি একটি আরপিএম তৈরি করছি যা জাভা-১.০.০-ওপেনজেডকে প্রয়োজনীয়গুলিতে রয়েছে: লাইন; তবে জাভা 7 দিয়ে; আমি জাভা-১.7.০-ওপেনজেডকেও সমর্থন করতে চাই তবে এই দু'জনের
কোনওটিরই

আপনি যদি বার-ফু এর প্যাকেজিং নিয়ন্ত্রণ করেন তবে এর একটি সম্ভাব্য সমাধান হ'ল এটি তৈরি করা Provides: foo-bar, সুতরাং এটি উভয় নির্ভরতা সন্তুষ্ট করে। নতুন আরপিএম সংস্করণগুলির জন্য, বুলিয়ান নির্ভরতাগুলি পরীক্ষা করুন । বিভাগ %preএবং %postবিভাগ থেকে দূরে থাকুন , সিস্টেমকে পরাস্ত করার চেষ্টা করবেন না
ফোর্সফেস্ক

উত্তর:


13

RPM 4.13 হিসাবে এটি এখন সম্ভব।

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

এটি কেবল সহজ হতে পারে: Requires: (pkgA >= 3.2 or pkgB)


দস্তাবেজ থেকে মনে হচ্ছে এগুলি প্রয়োজনীয়গুলির সাথে ব্যবহার করা যাবে না, কেবলমাত্র 'দুর্বল' নির্ভরতা সঠিক?

দ্বিতীয় লিঙ্কটি দেখায় যে এগুলি প্রয়োজনীয়গুলির সাথে ব্যবহার করা যেতে পারে। প্রথম লিঙ্কটিতে উল্লেখ করা হয়েছে যে ফেডোরায় সেভাবে এটি ব্যবহার করার অনুমতি নেই তবে এটি কাস্টম প্যাকেজগুলির ক্ষেত্রে প্রযোজ্য নয়।
carlwgeorge

9

এই জাতীয় আচরণ ইতিমধ্যে বেশ কয়েকটি প্যাকেজ দ্বারা সম্পন্ন হয়েছে, উদাহরণস্বরূপ মেল পরিবহণ এজেন্ট। এই ভার্চুয়াল প্যাকেজগুলি আপনার সিস্টেমকে এটির জানার একটি উপায় সরবরাহ করে যা তাদের প্রয়োজনীয় সক্ষমতা ইতিমধ্যে অন্য কোনও প্রোগ্রাম দ্বারা সরবরাহ করা হয়েছে কিনা।

দেখুন rpm.org এ ভার্চুয়াল প্যাকেজগুলির উদাহরণ আপনাকে সহায়তা করে কিনা।


ধন্যবাদ। আমি মনে করি না যে ভার্চুয়াল প্যাকেজগুলি এখানে আমার নির্দিষ্ট সমস্যাটি সমাধান করবে, তবে আমি সম্মত হই যে সেগুলি খুব কার্যকর। আমার ক্ষেত্রে আমি উভয় দ্বারা উপলব্ধ কিছু সাধারণ বৈশিষ্ট্য প্রয়োজন চাই না foo-barএবং bar-foo, এবং যেহেতু আমি নিয়ন্ত্রণ করে না প্যাকেজিং foo-barআমি শুধু তাদের উভয় প্রদান করতে পারবেন না support-for-mypackage। যদি আমি উভয় বিকল্প পূর্বশর্তগুলির প্যাকেজিং নিয়ন্ত্রণ করি তবে প্রকৃতপক্ষে একটি ভাগ করা ভার্চুয়াল প্যাকেজ একটি দুর্দান্ত সমাধান হবে।
কেভিন ফ্রস্ট

5

দুটি সম্ভাবনা:

যদি অংশ foo-barএবং bar-fooআপনি ব্যবহার একটি সাধারণ ফাইল আপনি শুধু পারেন Require /path/to/file(আমি মনে করি তাই আমার পরীক্ষামূলক সীমিত ছিল)।

আপনার পরিস্থিতি alচ্ছিক নির্ভরতাগুলির মতো। তারা যেভাবে পরিচালিত হয় তা হল একটি X-commonপ্যাকেজ এবং তারপরে X-foo-barপ্রয়োজনীয় foo-barএকটি X-bar-fooপ্যাকেজ এবং প্রয়োজনীয় প্যাকেজ bar-foo


দুর্ভাগ্যক্রমে কোনও সাধারণ ফাইল নেই। এটি যদি একটি দুর্দান্ত কৌশল ছিল তবে এটি সম্ভাব্য বিপজ্জনক হলেও: ভবিষ্যতের কিছু সংস্করণ foo-barএর ফাইলগুলি সরিয়ে নিতে পারে (আমি কেবল bar-fooএখানেই নিয়ন্ত্রণ করি )। Alচ্ছিক নির্ভরতা আকর্ষণীয় তবে আমার যা প্রয়োজন তা পুরোপুরি নয়, যেহেতু আমার সত্যিই প্রয়োজন হয় foo-bar বা হয়bar-foo ; alচ্ছিক একমাত্র জিনিস যা পছন্দ। জবাব দেওয়ার জন্য ধন্যবাদ
কেভিন ফ্রস্ট

এটা আমার সমস্যা সমাধান! বিভিন্ন জিএনইউ / লিনাক্স স্বাদে পাইথন 3 ভার্চুয়াল প্যাকেজগুলি সরবরাহ করে: পাইথন 3, পাইথন 34, পাইথন 35 ইত্যাদি my আমার একক প্যাকেজ সমস্তটিতে কাজ করার জন্য, আমি কেবল ব্যবহার করতে সক্ষম Require: /usr/bin/python3
হয়েছি

0

আপনার প্যাকেজ বার-ফু ভার্চুয়াল প্যাকেজ ফু-বার সরবরাহ করা কি আপনার পক্ষে কাজ করবে?

তারপরে আপনি কেবল নিজের বার্প-বাজ প্যাকেজটির জন্য ফু-বারের প্রয়োজন।


উপরের কাজটি করা যদি কঙ্কাল বোধ করে (এটি সম্ভবত) আপনার আরপিএমের দুটি সংস্করণ তৈরি করতে হতে পারে, একটি নির্ভর করে foo-barএবং অন্যটি নির্ভর করে bar-foo


লোভনীয়, তবে বিপজ্জনক: অন্য কিছু, যা সত্যই প্রয়োজন হয় foo-bar, তারপরে ভাঙতে পারে যদি মনে bar-fooহয় যে এটি এমন কিছু সরবরাহ করছিল যা এটি আসলে ছিল না। স্টিকিং পয়েন্টটি হ'ল আমার প্যাকেজের জন্য আমার পূর্বশর্তগুলির প্রয়োজন হয় তবে উভয়ই নয়; তবে অন্য যে কোনও প্যাকেজের জন্য তাদের মধ্যে কেবল একটির প্রয়োজন হতে পারে। এবং আমি উভয়ই উভয়ের প্রয়োজন বোধ করতে পারি না, যেহেতু এমন আসল কেস রয়েছে যেখানে কেবল এক বা অন্য উপলব্ধ থাকবে।
কেভিন ফ্রস্ট

-2

অটোমেটেড সিস্টেমগুলিতে অ-নির্ধারণবাদ (যা হয় নির্ভরতা পরিচালনা বা মেশিনগুলি যা আরপিএম ব্যবহার করে) সত্যিই খারাপ জিনিস। আপনি এটি একটি-বা-পরিস্থিতিটি ব্যর্থ করতে চান, ব্যর্থতা এখনও অপ্রত্যাশিত ফলাফলের মতো খারাপ নয়।

সমস্যাটি সমাধান করার জন্য, প্যাকেজটি আপনার নিয়ন্ত্রণ করুন% অপরিবর্তনীয় প্যাকেজটি% সরবরাহ করে এবং যা আপনার অন্যান্য সফ্টওয়্যার% নির্ভর করে তা প্রধান টোকেন সরবরাহ করে; তারপরে আপনার প্যাকেজ% অপরিবর্তনীয় একটিকে অচল করে দেয়। বিশেষত যদি এটি ইতিমধ্যে স্থানে থাকে তবে আপনি এটি অন্য ইনস্টলের মাধ্যমে জিততে পারেন।

প্যাকেজিং এবং সঠিক নির্ভরতা এবং ইনস্টল অপারেশন কৌতুকপূর্ণ কাজ। লক্ষ্য - নির্ভরযোগ্য, পুনরাবৃত্তিযোগ্য, নিরীক্ষণযোগ্য ইনস্টলগুলি - এটি এত মূল্যবান যে আপনি এটি সঠিকভাবে অর্জনের লাভগুলি উপলব্ধি করতে পারেন।

নির্ভরতা নরক স্ব-নিপীড়িত। কোন আশা নাই


এই মাছটি আমি আপনাকে দেব: আপনার দুটির মধ্যে একটি মাত্র দরকার কারণ উভয়ই কিছু ফাইল বা সংস্থান সরবরাহ করে। সুতরাং,% প্যাকেজের নামের উপর নির্ভর করে না, কেবল তাদের ফাইল বা সংস্থান সরবরাহ করে। হ্যাঁ, আপনি এখনও অ-নির্ধারিততার প্রতিদ্বন্দ্বিতা করছেন, তবে আপনি যদি সরাসরি আরপিএমডিবি দিয়ে সরাসরি মাকিংয়ের বিষয়টি বিবেচনা করছেন তবে আপনি ইতিমধ্যে খুব খুশি হয়ে ঝুঁকিগুলি বিবেচনা করছেন যা বেশিরভাগ লোক এড়াতে শিখেছে। আমি আশা করি আপনি এমন একটি সমাধান খুঁজে পেতে পারেন যাতে এই জাতীয় প্রযুক্তি debtণ ব্যয় হয় না।
ব্যবহারকারী 2066657
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.