.Deb फ़ाइलों और .run फ़ाइल के बीच अंतर

10

.Deb फ़ाइलों को बनाने और उन्हें स्थापित करने और सिर्फ .run फ़ाइल चलाने के बीच क्या अंतर है ?

package-management

1

क्या आपके मन में विशेष उदाहरण हैं?

— slm

8

.debफाइलें dpkg के लिए पैकेज हैं , निम्न-स्तरीय डेबियन पैकेज प्रबंधक (जो APT और उसके रिश्तेदारों द्वारा हुड के तहत मंगवाया गया है)। एक .debफ़ाइल डेबियन के लिए या Ubuntu या टकसाल के रूप में एक व्युत्पन्न ऐसे के लिए एक पैकेज है।

डेबियन पैकेज में वे फाइलें होती हैं जो पैकेज के साथ-साथ एक "कंट्रोल फाइल" होती हैं, जो पैकेज की निर्भरता और अन्य मेटा-जानकारी और पैकेज स्थापित होने, अपग्रेड या अनइंस्टॉल होने पर निष्पादित स्क्रिप्ट्स का वर्णन करती हैं।

आप के .debसाथ dpkg -cऔर एक फ़ाइल की सामग्री को देख सकते हैं dpkg -I। यदि आपके पास नहीं है dpkg, तो आप ar t foo.debकिसी .debफ़ाइल के हिस्सों को सूचीबद्ध करने और भाग ar x foo.deb control.tar.gzनिकालने के लिए उपयोग कर सकते हैं control.tar.gz(और इसी तरह अन्य भागों के लिए)।

Red Hat (और CentOS और फेडोरा जैसे रिश्तेदार), SuSE और अन्य समान विशेषताओं वाले एक अलग प्रारूप rpm का उपयोग करते हैं । कर रहे हैं दूसरों के अन्य यूनिक्स सिस्टम पर।

.runएक मानक विस्तार नहीं है। एक .runफ़ाइल संभवतः कुछ ऐसा है जिसे आप निष्पादित कर सकते हैं। यह एक प्रोग्राम स्थापित कर सकता है या कुछ पूरी तरह से अलग कर सकता है।

— गिल्स 'SO- बुराई होना बंद करो'
स्रोत

8

सामान्य तौर पर .deb फ़ाइल एक ज़िप फ़ाइल के समान होती है, जिसमें छोटी स्क्रिप्ट के साथ फाइलें होती हैं जो स्थापना के बाद सिस्टम में उपयोगकर्ताओं, समूहों आदि को जोड़ने के लिए पोस्ट इंस्टॉलेशन को चला सकती हैं।

एक .run फ़ाइल आमतौर पर एक एकल बाइनरी निष्पादन योग्य या शेल स्क्रिप्ट होती है जिसमें एक बाइनरी बूँद होती है जिसे इंस्टॉल किया जा सकता है। यदि यह शेल स्क्रिप्ट की विविधता है तो इसमें अक्सर एक बाइनरी ब्लॉब होता है जो अक्सर एक पुनरावर्ती ज़िप फ़ाइल या टार फ़ाइल का पर्याय बन जाता है। दूसरे शब्दों में इसमें फाइलों की निर्देशिका संरचनाएं होंगी।

अन्य समय में .run फ़ाइल में इस प्रकार की .deb या .rpm फाइलें होती हैं, जो डिस्क से बाहर डंप हो जाएंगी, और या तो व्यक्तिगत रूप से इंस्टॉल की जा सकती हैं, या स्क्रिप्ट जिसमें उन्हें समाहित किया गया है, उन्हें डिस्क में डंप कर देगा, और फिर प्रयास करें। अपने सिस्टम के पैकेज मैनेजर सॉफ्टवेयर का उपयोग करके उन्हें स्थापित करने के लिए।

इसका एक उदाहरण यह होगा कि यदि आप Oracle से जावा JDK डाउनलोड करते हैं। यह आमतौर पर एक एकल निष्पादन योग्य फ़ाइल है कि जब मार डाला डिस्क के लिए बाहर .deb अथवा .rpm फ़ाइलों डंप हो जाएगा, और फिर उन्हें का उपयोग कर स्थापित है the package management tools: dpkg, apt, yum, या rpm।

उदाहरण

यहाँ एक उदाहरण है कि इनमें से एक .run फ़ाइलों के साथ डाउनलोड / इंस्टॉलेशन कैसा दिखेगा। एक्सटेंशन .bin है, लेकिन यह केवल कॉस्मेटिक है, उपयोगकर्ताओं की विभिन्न प्रकार की फ़ाइलों के बीच अंतर करने में मदद करने के अलावा विस्तार वास्तव में कोई प्रासंगिकता नहीं है।

$ wget http://www.java.net/download/jdk7/archive/b125/binaries/jdk-7-ea-bin-b125-linux-x64-13_jan_2011.bin
$ ./jdk-7-ea-bin-b125-linux-x64-13_jan_2011.bin

यहां उपरोक्त फ़ाइल JDK बनाने वाले विभिन्न घटकों के लिए पैकेजों को डंप कर देगी, जिसके बाद आप उन सभी या बस उन लोगों को स्थापित कर सकते हैं जिनकी आपको आवश्यकता है।

क्या यह इस तरह से अतिरिक्त चीजों को सिर्फ एक पैकेज स्थापित करने से परे करने की अनुमति देता है। उदाहरण के लिए ओरेकल के पास एक लाइसेंस समझौता है जो वे चाहते हैं कि आप स्वीकार करें:

10.5 यह समझौता अपने विषय से संबंधित पक्षों का संपूर्ण समझौता है। यह सभी पूर्व या समकालीन मौखिक या लिखित संचार, प्रस्तावों, शर्तों, अभ्यावेदन और वारंटियों को अधिगृहीत करता है और किसी भी बोली सहित पार्टियों के बीच किसी भी बोली, आदेश, पावती, या अन्य संचार के किसी भी परस्पर विरोधी या अतिरिक्त ते rms पर प्रबल होता है। नैरी कोड लाइसेंस, पूरक शर्तें, या लाइसेंस प्राप्त सॉफ्टवेयर के भीतर निहित अन्य लाइसेंस। इस समझौते में कोई संशोधन बाध्यकारी नहीं होगा, जब तक कि प्रत्येक पार्टी के अधिकृत प्रतिनिधि द्वारा लिखित और हस्ताक्षरित न हों।

क्या आप उपरोक्त लाइसेंस शर्तों से सहमत हैं? [हाँ या ना]

इस उपरोक्त इंस्टॉलर के साथ आप देख सकते हैं कि इसमें फ़ाइलों की निर्देशिकाओं का एक द्विआधारी बूँद है:

Extracting...
UnZipSFX 5.52 of 28 February 2005, by Info-ZIP (http://www.info-zip.org).
   creating: jdk1.7.0/
   creating: jdk1.7.0/lib/
  inflating: jdk1.7.0/lib/jexec      
   creating: jdk1.7.0/lib/visualvm/
   creating: jdk1.7.0/lib/visualvm/visualvm/
   creating: jdk1.7.0/lib/visualvm/visualvm/modules/
  inflating: jdk1.7.0/lib/visualvm/visualvm/modules/com-sun-tools-visualvm-attach.jar  
  inflating: jdk1.7.0/lib/visualvm/visualvm/modules/com-sun-tools-visualvm-host-views.jar  
   creating: jdk1.7.0/lib/visualvm/visualvm/modules/locale/
...

इस मामले में इस प्रकार की स्थापना पैकेज मैनेजर को बुलाने के लिए नहीं है, बल्कि सामग्री को केवल एक डायरेक्टरी ट्री में डंप करने के लिए है ताकि आप इसे अपनी इच्छा के अनुसार इधर-उधर ले जा सकें।

उत्पादन के वातावरण में अक्सर ऐसा होता है कि आप पैकेज मैनेजर का उपयोग नहीं करना चाहते हैं, बल्कि तैनाती पर अधिक नियंत्रण रखते हैं। शायद आपके पास कई एप्लिकेशन हैं जिन्हें आप तैनात कर रहे हैं और उनमें से प्रत्येक को जेडीके के एक अलग संस्करण की आवश्यकता है। इस पद्धति का उपयोग करके आप उन सभी सह-कलाकारों को अधिक आसानी से कह सकते हैं, फिर पैकेज प्रबंधक के माध्यम से कह सकते हैं।

$ pwd
/home/saml/jdk1.7.0
[saml@grinchy jdk1.7.0]$ ls -l
total 19308
drwxr-xr-x  2 saml saml     4096 Jan 13  2011 bin
-r--r--r--  1 saml saml     2487 Jan 13  2011 COPYRIGHT
drwxr-xr-x  5 saml saml     4096 Jan 13  2011 db
drwxr-xr-x 11 saml saml     4096 Jan 13  2011 demo
drwxr-xr-x  3 saml saml     4096 Jan 13  2011 include
drwxr-xr-x  6 saml saml     4096 Sep 29 10:57 jre
drwxr-xr-x  3 saml saml     4096 Sep 29 10:57 lib
-r--r--r--  1 saml saml     9005 Jan 13  2011 LICENSE
drwxr-xr-x  4 saml saml     4096 Jan 13  2011 man
-r--r--r--  1 saml saml    25379 Jan 13  2011 README.html
-r--r--r--  1 saml saml    20320 Jan 13  2011 README_ja.html
-r--r--r--  1 saml saml    15160 Jan 13  2011 README_zh_CN.html
-r--r--r--  1 saml saml     5348 Sep 29 10:58 register.html
-r--r--r--  1 saml saml     5645 Sep 29 10:58 register_ja.html
-r--r--r--  1 saml saml     4951 Sep 29 10:58 register_zh_CN.html
drwxr-xr-x  8 saml saml     4096 Jan 13  2011 sample
-rw-r--r--  1 saml saml 19631790 Jan 13  2011 src.zip

संदर्भ

— slm
स्रोत