সফ্টওয়্যার উত্স ফাইল রাখার জন্য মানক অবস্থান


16

সোর্স ফাইল রাখার জন্য লিনাক্সে কি কোনও আদর্শ অবস্থান রয়েছে উদাহরণস্বরূপ ওপেনএসএসএল । আমি ওপেনএসএসএল এর অ ডিফল্ট সংস্করণ সহ উত্স থেকে এনগিনেক্স তৈরি করছি। আমাকে ওপেনএসএসএল ডাউনলোড এবং আনটার দরকার এবং আমি হোম ডিরেক্টরিতে এটি করেছি। এখন, আমি অবাক হয়েছি লিনাক্সে সম্ভবত কোনও মানক অবস্থান রয়েছে /opt?


1
যেমন টেরডন লিখেছেন / usr / src স্ট্যান্ডার্ড লোকেশন, এবং আপনি এখানে কার্নেল উত্সের জন্য ডিরেক্টরিগুলি (/ usr / src / linux / usr / src / linux-version এর সাথে সংযুক্ত) এবং উদাহরণস্বরূপ X11 পেতে পারেন। স্থানীয়ভাবে ইনস্টল করা প্যাকেজগুলির জন্য উত্স-কোড (/ usr / স্থানীয়) / usr / স্থানীয় / src এ আরও ভাল ফিট করে fits আপনি যদি নিজেই "ম্যানুয়ালি" প্যাকেজগুলি তৈরি করতে চান, আপনার বাড়ির অভ্যন্তরে একটি সিআরসি-ডিরেক্টরি তৈরি করা সম্ভবত একটি ভাল ধারণা ... মনে রাখবেন আপনার ডাউনলোড, আনপ্যাক বা রুট হিসাবে তৈরি করা উচিত নয় - কেবল ইনস্টল করুন! আপনি যদি ডিবে / আরপিএম-প্যাকেজগুলি তৈরি করেন তবে অস্থায়ী বিল্ড ডিরেক্টরিগুলি (উদাহরণস্বরূপ / var / tmp এর অধীনে) সাধারণত ব্যবহৃত হয়। টিবিসি
বার্ড কোপ্পেরুদ

আপনি যদি একটি প্যাকেজ তৈরি এবং ইনস্টল করেন - বা নিজেই একটি প্যাকেজ (rpm / dem) তৈরি করেন - সাধারণত ইনস্টল করার পরে আপনার আর উত্স-কোডের প্রয়োজন হয় না। কিছু প্যাকেজগুলির জন্য সোর্স-কোড থাকতে পারে - যেমন কার্নেল বা এক্স 11 - / usr / src এর অধীনে (অথবা / usr / স্থানীয় / এসসিআর যদি এটি স্থানীয়ভাবে তৈরি করা হয়েছিল) তবে বেশিরভাগ কারণে আপনার প্রয়োজন হতে পারে যদি আপনি ' পুনরায় বিল্ডিং (বা লিখন) নিজেই কিছু সফ্টওয়্যার প্যাকেজ তৈরি করে (যেমন কার্নেল থেকে কিছু অস্পষ্ট শিরোলেখ-ফাইলগুলি, আপনার প্রকৃত সিস্টেমের সেট আপের সাথে মিলে যায়)। (অবশ্যই, আপনি যদি এটির নিজস্ব কার্নেলও তৈরি করতে চান তবে আপনার এটি প্রয়োজন ...) তবে এটি কয়েকটি প্যাকেজের ক্ষেত্রে প্রযোজ্য।
বার্ড কোপ্পেরুদ

উত্তর:


20

আপনি যখনই নিজেকে এই জাতীয় কিছু জিজ্ঞাসা করবেন তখন ফাইল সিস্টেম হায়ারার্কি স্ট্যান্ডার্ড (এফএইচএস) দেখুন hereএখানে, আপনি নীচের প্রবেশিকাটি পাবেন:

ইউএসআর / এসসিআর: উত্স কোড (alচ্ছিক)

উদ্দেশ্য

উত্স কোডটি কেবলমাত্র রেফারেন্সের উদ্দেশ্যে এই সাব-ডিরেক্টরিতে স্থাপন করা যেতে পারে

সুতরাং আপনি আপনার উত্স ফাইলগুলি উপ-ডিরেক্টরিতে রাখতে পারেন /usr/src। এটি বলেছিল, এটি একটি .চ্ছিক ডিরেক্টরি যাতে আপনি যেখানে খুশি সেখানে সত্যিই রাখতে পারেন। উত্স কোডটি আপনি এটি কার্যকর করার যোগ্য হিসাবে সংকলন করার পরে প্রাসঙ্গিক নয় সুতরাং সিস্টেমটিকে কোনও নির্দিষ্ট স্থানে অ্যাক্সেসযোগ্য হওয়ার জন্য কোনও কিছুর উত্সের প্রয়োজন হবে না।

উপসংহারে: /usr/srcএটি একটি দুর্দান্ত মানক অবস্থান তবে আপনি যদি পছন্দ করেন তবে নিজের পছন্দ করতে নির্দ্বিধায়।


6
কেবল সচেতন হোন যে আপনি সত্যিই/usr/src একটি নন- লিনাক্স সিস্টেমে গোলমাল করতে চান না । বিএসডিগুলি তাদের বেস সিস্টেম উত্সগুলি ডিফল্টরূপে সেখানে রাখে এবং আপনি তাদের তৃতীয় পক্ষের সফ্টওয়্যার দ্বারা মিলিত করতে চান না। শুধু আপনার $HOMEকোথাও নির্মিত ...
কুসালানন্দ

1
একই কিছু উপ-ডিরেক্টরির প্রযোজ্য /usr/srcডেবিয়ান ডেরাইভেটিভস, যদি আপনি নির্দিষ্ট প্যাকেজ ইনস্টল করা আছে ( gcc-6-source, binutils-source, প্যাকেজ DKMS, কার্নেল হেডার ইত্যাদি)। ডেবিয়ান-তে, একটি দুর্দান্ত বৈশিষ্ট্য রয়েছে যেখানে আপনি নিজের srcমালিকানাধীন গোষ্ঠীতে নিজেকে যুক্ত করতে পারেন /usr/srcএবং তারপরে কেবল নিজের মতো করে লিখুন (কোনও প্রয়োজন sudoবা কিছু না করে)।
স্টিফেন কিট

এবং ফেডোরায় , আপনার স্পর্শ করা উচিত নয় /usr/src/debugএবং /usr/src/kernels(এএএএফআইএস)।
স্টিফেন কিট

"উত্স কোড স্থাপন করা যেতে পারে"। "স্থান" একটি টাইপো আছে, বা আমি কিছু মিস করছি?
ফাহিম মিঠা

3
আমি আরও এগিয়ে যাব এবং বলব আপনার /usrকোনও সিস্টেমে সত্যই স্পর্শ করা উচিত নয় । আপনার জিনিস রাখা উচিত /usr/local। BSDs আপনি ব্যবহার মনে করেন /usr/local/src?
মুজার 11

13

/usr/local/srcউত্স কোড রাখতে একটি নিরাপদ জায়গা এবং এটিও বানাতে। এফএইচএস বলে :

Directory   Description  
src         Local source code

এবং যদিও

স্থানীয়ভাবে সফ্টওয়্যার ইনস্টল করার সময় সিস্টেম / প্রশাসক দ্বারা / usr / স্থানীয় শ্রেণিবিন্যাস ব্যবহার করা হয়। সিস্টেম সফ্টওয়্যার আপডেট হলে এটি ওভাররাইট হওয়া থেকে নিরাপদ হওয়া দরকার।

এটি "স্থানীয় উত্স কোড" এর অর্থ কী তা পরিষ্কার নয় তবে এটি পরিষ্কার হয়ে গেছে যে সিস্টেমটি এর /usr/local/srcবিপরীতে কিছু রাখার চেষ্টা করবে না /usr/src, সুতরাং কোডটি রাখার ক্ষেত্রে কিছুটা খারাপ দিক বলে মনে হচ্ছে।

আসলে, আমার একটি পৃথক ফাইল সিস্টেম রয়েছে:

Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/data-local_src     79G   46G   30G  61% /usr/local/src

নোট: ডেবিয়ান উপর অন্তত, আপনার ব্যবহারকারী যোগ করা প্রয়োজন staffলিখতে অনুক্রমে গ্রুপ /usr/local


/usr/local/srcঅন্যান্য উত্তরগুলি কেবল আলোচনা করার সময় +1 /usr/src
দেখানোর

"স্থানীয় উত্স কোড" এর অর্থ কী, সাধারণভাবে এর অর্থ বিতরণ না করে স্থানীয় সিসাদমিন দ্বারা নিয়ন্ত্রিত । (তত্ত্বের অধীনে ) সমস্ত কিছুর সমান । সুতরাং মূলত এর অর্থ হ'ল আপনি যা বর্ণনা করেছেন। /usr/local
ম্যাটস্টারজন

9

যদি "স্ট্যান্ডার্ড" বলতে আপনার অর্থ প্রচলিত হয়, তবে উত্স কোড আনপ্যাক এবং তৈরি করার জায়গাটি আপনার হোম ডিরেক্টরি। এই জাতীয় ফাইলগুলি ক্ষণস্থায়ী, আপনার কাজ শেষ হয়ে গেলে মুছে ফেলা বা আপনি চাইলে রাখা হয়, তবে আপনি দয়া করে সংঘবদ্ধ বলে আশা করা হচ্ছে। আপনার বাড়ির ডিরেক্টরিটি হ'ল এই জাতীয় ধরণের স্টাফের সাথে খেলার জন্য।

আপনি যদি পরে সেগুলি রাখতে চান , তবে রেফারেন্সের জন্য , " ফাইল সিস্টেম হায়ারার্কি স্ট্যান্ডার্ড " সুপারিশ করে /usr/src। তবে এটি একটি আইন নয় একটি গাইড; এবং, যদি আপনি এই অভ্যাসে প্রবেশ করতে চান তবে একটি নন-লিনাক্স সিস্টেমের দিকে চালিত হন, আপনি এটি অনুসরণ করে সমস্যার কারণ হতে পারেন। উদাহরণস্বরূপ, একটি বিএসডি সিস্টেমে, বেস সিস্টেম উত্সগুলি সেখানে রাখা হয় এবং আপনি সত্যিই সেগুলির সাথে বিশৃঙ্খলা করতে চান না। এমনকি লিনাক্সেও আপনি প্যাকেজ পরিচালকদের দ্বারা সঞ্চিত যে কোনও উত্সের সাথে মিশে যাওয়ার ঝুঁকিটি চালাতে পারেন, এটি পছন্দসই নয়।

আমি /usr/srcসামগ্রিকভাবে এড়ানো পরামর্শ দিচ্ছি । এখানে কিছু রাখার কোনও সুস্পষ্ট সুবিধা নেই এবং আপনি যদি এর উদ্দেশ্যযুক্ত অর্থ গুলিয়ে দেন তবে সম্ভাব্য ঝুঁকি।


5

আপনি /usr/srcএই জায়গাটি যুক্তিযুক্ত হিসাবে ব্যবহার করতে পারেন এবং আরপিএম ভিত্তিক বিতরণগুলি সেখানে এসআরএম প্যাকেজগুলির সামগ্রী সংরক্ষণ করতে ব্যবহার করে। কিন্তু অন্য কোন স্থানের মত /opt, /usr/local, ~/srcভালো


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