Repositories and Priority.hi

EN · EL · FR · ES · IT · RU · ZH · AR · HI · PT · DE

रिपॉज़िटरी और प्राथमिकता

यही slacker का परिभाषक विचार है, और यही उसे एक साधारण मिरर-उपकरण से अलग करता है: हर रिपॉज़िटरी एक ही प्राथमिकता-क्रमित मॉडल में रहता है, और प्राथमिकता का कभी चुपचाप उल्लंघन नहीं होता।

---

प्राथमिकता नियम

जब एक ही पैकेज-नाम कई रिपॉज़िटरीयों द्वारा दिया जाता है, तो सर्वोच्च प्राथमिकता वाले रिपॉज़िटरी का जीतता है। इससे भी महत्वपूर्ण:

कोई स्थापित पैकेज कभी चुपचाप किसी अन्य रिपॉज़िटरी में स्थानांतरित नहीं होता, और कभी पदावनत नहीं होता। उम्मीदवार केवल अधिक या समान प्राथमिकता वाले रिपॉज़िटरी से ही प्रस्तावित होता है। एकमात्र अपवाद एक स्पष्ट repo:name है।

इस प्रकार, किसी रिपॉज़िटरी को एक अलग, ऊँची प्राथमिकता देना उसके पैकेजों को तालाबंद कर देता है: किसी निचले रिपॉज़िटरी की कोई चीज़ उन्हें नहीं बदल सकती, चाहे संस्करण संख्या नई ही क्यों न हो।

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#161b22','primaryBorderColor':'#1f6feb','primaryTextColor':'#e6edf3','lineColor':'#6e7781','fontFamily':'monospace'}}}%%
flowchart TB
  I["स्थापित पैकेज<br/>(उसका build tag = उसका स्रोत)"] --> D{"उम्मीदवार रिपो की प्राथमिकता<br/>बनाम स्थापित स्रोत"}
  D -->|अधिक या समान| U["उन्नत / प्रतिस्थापित कर सकते हैं"]
  D -->|कम| K["रखा गया - कभी पदावनत नहीं<br/>कभी स्थानांतरित नहीं"]
  PIN["repo:name"] -. "एक रिपो बाध्य करता है,<br/>प्राथमिकता को लाँघकर" .-> U
  classDef grey fill:#0d1117,stroke:#6e7781,color:#8b949e;
  classDef blue fill:#0d1117,stroke:#1f6feb,color:#e6edf3;
  classDef green fill:#0d1117,stroke:#2ea043,color:#e6edf3;
  class I,PIN grey
  class D blue
  class U green
  class K grey

Loading

बिना किसी डेटाबेस के slacker किसी स्थापित पैकेज का «स्रोत» कैसे जानता है? उसके build tag से — build क्षेत्र में से आरंभिक अंक घटाकर (1_SBo → _SBo, 7cf → cf, 1 → आधिकारिक)। उपयोक्ता की एक tag-priority पंक्ति, या वह सर्वोच्च-प्राथमिकता बाइनरी रिपॉज़िटरी जो वह टैग देता है (cf → conraid, alien → alienbob, स्वतः पहचाना गया), तय करता है कि वह किस प्राथमिकता का है।

---

repos फ़ाइल

# priority  name        url|mirror|mirror/<subpath>                          [flags]
100         slackware   mirror                                                official
200         patches     mirror/patches                                        subtree immutable
90          extras      mirror/extra                                          subtree immutable
85          testing     mirror/testing                                        subtree immutable
80          conraid     https://slackers.it/repository/slackware64-current    immutable
60          alienbob    https://slackware.nl/people/alien/sbrepos/current/x86_64
# tag-priority पंक्तियाँ (एक प्राथमिकता साझा कर सकती हैं):
100         SBo         _SBo
100         local       _rtz

URL क्षेत्र

रूप	अर्थ
एक शब्दशः URL	https://, http://, या file:// (अंतिम — स्थानीय क्लोन / NFS / आरोहित माध्यम के लिए — निरपेक्ष पथ हेतु तीन स्लैश)
mirror	mirrors की सक्रिय पंक्ति, ज्यों-की-त्यों — आधिकारिक रिपॉज़िटरी के लिए इसका उपयोग करें
mirror/<उप-पथ>	सक्रिय मिरर जिसमें एक उप-पथ जोड़ा गया हो (mirror/extra, mirror/testing, mirror/patches) — एक उप-वृक्ष जो आपके चुने मिरर का अनुसरण करता है

URL PACKAGES.TXT वाले रिपॉज़िटरी की जड़ की ओर इंगित करता है; आधिकारिक मिरर के लिए MANIFEST.bz2 प्रति-आर्किटेक्चर उप-निर्देशिका में रहता है, जिसे slacker स्वतः खोज लेता है।

flags

Flag	यह क्या करता है
official	अनुसरित रिपॉज़िटरी को चिह्नित करता है: यह show-changelog को चलाता है और install-new के लिए डिफ़ॉल्ट है। स्थान फिर भी केवल प्राथमिकता से तय होता है — आधिकारिक रिपॉज़िटरी कहीं भी रह सकता है।
immutable	इस रिपॉज़िटरी को सौंपा गया हर पैकेज clean-system से बाहर रखा जाता है। जिन extra/testing/patches को आप स्थापित रखते हैं, उनके लिए हर एक को ब्लैकलिस्ट करने के बजाय इसका उपयोग करें।
subtree	यह URL एक Slackware वितरण उप-वृक्ष है (extra, patches, testing, pasture)। उनका PACKAGES.TXT स्थानों को वितरण की जड़ के सापेक्ष सूचीबद्ध करता है, इसलिए पैकेज और GPG-KEY मूल (जड़) URL से लाए जाते हैं जबकि मेटाडेटा स्वयं URL से आता है। इसके बिना, वे पैकेज दोहरे पथ-खंड के साथ 404 देते हैं। चारों उप-वृक्षों को यह flag सदा धारण करना चाहिए।
verify=...	प्रति-रिपॉज़िटरी सत्यापन अधिभावी (देखें Security)।

mirror/extra + subtree एक जोड़ी हैं। mirror/extra URL को सुलझाता है; subtree यह ठीक करता है कि उससे पैकेज और कुंजी कैसे लाए जाएँ।

---

पिनिंग और चयनक

कमांड-लाइन पर एक PATTERN हो सकता है:

रूप	मेल खाता है
firefox	ठीक-ठीक पैकेज नाम
python	नाम की एक उप-स्ट्रिंग — सभी python-*
kde	एक Slackware श्रृंखला (a, ap, d, k, kde, l, n, t, x, xap, xfce, y, …) — केवल वही श्रृंखला, कभी उप-स्ट्रिंग नहीं
repo:name	एक pin — प्राथमिकता की परवाह किए बिना एक रिपॉज़िटरी बाध्य करता है (जैसे alienbob:vlc)
@repo	एक समुच्चय-चयनक — उस रिपॉज़िटरी का हर पैकेज (install @gnome, remove @gnome)
@_tag	उस build टैग वाला हर पैकेज (remove @_SBo)

@ अनिवार्य है, ताकि कोई नंगा शब्द कभी रिपॉज़िटरी न समझ लिया जाए। एक अज्ञात @repo/@_tag एक «did you mean» सुझाव देता है और उपलब्ध रिपॉज़िटरी तथा टैग सूचीबद्ध करता है। इसके उलट, एक नंगा शब्द जो पैकेज नहीं बल्कि रिपॉज़िटरी का नाम है (download fontforge ponce — छूटा हुआ :), उसका उत्तर निकटतम पैकेज-नाम से नहीं दिया जाता: slacker बताता है कि वह रिपॉज़िटरी है और दोनों रूप देता है, ponce:<package> और @ponce।

एक ही कमांड में नंगे पैकेज-नाम को @repo के साथ न मिलाएँ। install vlc @alienbob का अर्थ बनता है «vlc और alienbob का हर पैकेज», जो लगभग कभी अभीष्ट नहीं होता — slacker इसे अस्वीकार करता है और alienbob:vlc की ओर संकेत करता है। हर रूप अकेले अपरिवर्तित रहता है: @repo अब भी पूरा रिपॉज़िटरी लेता है, कई @repo एक साथ चलते हैं, और repo:name पिन @repo के साथ रह सकता है क्योंकि वह अपना रिपॉज़िटरी पहले ही नाम से बता देता है और फैल नहीं सकता।

कोई भी आर्गुमेंट जो कुछ भी नहीं मिलाता, पूरी कमांड रद्द कर देता है। install, upgrade, reinstall, remove और download अपने सभी आर्गुमेंट पर काम करते हैं या किसी पर नहीं: यदि एक भी कुछ नहीं मिलाता, तो कुछ नहीं होता और उस आर्गुमेंट का नाम बता दिया जाता है। -y इसे नहीं लाँघता।

जब कोई पैटर्न एक से अधिक पैकेजों से मेल खाता है, तो install/upgrade/reinstall/ remove एक क्रमांकित सूची दिखाते हैं — सभी के लिए Enter, 1 3 5 या 2-4 जैसी संख्याएँ/परास, रद्द करने हेतु n।

कमांड-लाइन चयन के लिए कोई * वाइल्डकार्ड नहीं है। बिना उद्धरण का * slacker के चलने से पहले आपकी शेल द्वारा वर्तमान निर्देशिका के फ़ाइल-नामों में विस्तारित हो जाता है (slacker कभी * नहीं देखता और न ही आपकी निर्देशिका पढ़ता है); यदि इससे गैर-पैकेज तर्कों की बाढ़ बने, तो slacker इसे पहचान लेता है और आदेश अस्वीकार कर देता है, बिना कुछ बदले। किसी शब्दशः पैटर्न को उद्धरण में रखें, या पूरे रिपॉज़िटरी के लिए @repo का उपयोग करें। (Blacklist ही एकमात्र स्थान है जहाँ पैटर्न वास्तव में glob/regex होते हैं।)

---

CLI से रिपॉज़िटरी प्रबंधन

slacker add-repo  85 ktown https://slackware.nl/people/alien/ktown/current/x86_64
slacker add-repo  90 extras mirror/extra subtree immutable
slacker del-repo  ktown
slacker pri-repo  95 extras          # किसी मौजूदा रिपो की प्राथमिकता पुनः समायोजित करें
slacker add-tag   100 SBo _SBo
slacker del-tag   _SBo
slacker list-repos          # प्राथमिकता, verify, flags, स्थापित संख्या

ये कमांड नंगे रिपॉज़िटरी-नाम लेते हैं, @ के बिना। @ केवल वहीं है जहाँ नंगा शब्द अन्यथा पैकेज-नाम होता; install-new, clean-cache, vet-repo, trust-repo, distrust-repo, del-repo और pri-repo रिपॉज़िटरी के अलावा कुछ स्वीकार नहीं करते, इसलिए अलग बताने को कुछ है ही नहीं। install-new @ponce अस्वीकार होता है और नंगा नाम सुझाया जाता है।

add-repo पंक्ति को सत्यापित करता है और, पुष्टि पर, रिपॉज़िटरी को लाता और जाँचता (vets) है (देखें Security)।

pri-repo PRIORITY NAME उस रिपॉज़िटरी की प्राथमिकता बदलता है जो आपके पास पहले से है। यह जाँचता है कि NAME एक सक्रिय रिपॉज़िटरी है (टाइपो पर निकटतम मेल सुझाते हुए) और किसी ऐसी PRIORITY को अस्वीकार करता है जो कोई अन्य रिपॉज़िटरी पहले से रखता है, टकराव का नाम बताकर ताकि आप कोई और मान चुनें — प्राथमिकताएँ भिन्न ही रहनी चाहिए। केवल उसी पंक्ति की प्राथमिकता पुनः लिखी जाती है; URL और flags ठीक वैसे ही रहते हैं जैसे थे।