Official repositories (हिन्दी)

एक software repository एक storage location है जहाँ से software packages को installation के लिए retrieve किया जाता है।

Arch Linux official repositories में essential और popular software होता है, जो pacman के माध्यम से आसानी से accessible है। इन्हें package maintainers द्वारा maintain किया जाता है।

Official repositories में packages लगातार upgrade होते रहते हैं: जब कोई package upgrade होता है, तो उसका पुराना version repository से हटा दिया जाता है। कोई major Arch releases नहीं होती: हर package को upgrade किया जाता है जब नए versions upstream sources से available होते हैं। हर repository हमेशा coherent (सुसंगत) होती है, यानी इसमें host किए गए packages में हमेशा reciprocally compatible versions होते हैं।

Repository संरचना का विज़ुअलाइज़ेशन

Packages निम्नलिखित flow से होकर गुजरते हैं:

Upstream Source (डेवलपर का नया release)
         ↓
[Staging] ← Backend developers के लिए (broken packages, rebuilds)
         ↓
[Testing] ← User testing के लिए (core-testing, extra-testing, multilib-testing)
         ↓
[Stable]  ← सामान्य उपयोग के लिए (core, extra, multilib)

नोट: सभी packages इस पूरे flow से नहीं गुजरते। केवल critical या breaking changes वाले packages ही testing repositories में जाते हैं।

Stable repositories

निम्नलिखित table में तीनों stable repositories का quick comparison दिया गया है:

Repository	उद्देश्य	उदाहरण packages
core	System boot, networking, package building के लिए essential packages	linux, systemd, pacman, bash
extra	वे सभी packages जो core में fit नहीं होते (desktop environments, applications)	Xorg, KDE, GNOME, Firefox, LibreOffice
multilib	64-bit systems पर 32-bit applications को run करने के लिए	lib32-glibc, Steam के लिए dependencies

core

यह repository आपके पसंदीदा mirror पर .../core/os/ में मिल सकती है।

core में निम्नलिखित के लिए packages हैं:

Arch Linux को boot करना
Internet से connect होना
packages build करना
supported file systems का management और repair
system setup process (जैसे openssh)

साथ ही उपरोक्त की dependencies (जरूरी नहीं कि makedepends) और base meta package।

core की काफी strict quality requirements हैं। Package updates को accept करने से पहले Developers/users को updates पर signoff करना पड़ता है। कम उपयोग वाले packages के लिए, एक reasonable exposure काफी है: लोगों को update के बारे में सूचित करना, signoffs request करना, change की गंभीरता के आधार पर एक सप्ताह तक core-testing में रखना, outstanding bug reports की कमी, और package maintainer के implicit signoff के साथ।

Tip Internet connection के बिना core (या अन्य repositories) से packages के साथ एक local repository बनाने के लिए देखें Pacman tips

extra

यह repository आपके पसंदीदा mirror पर .../extra/os/ में मिल सकती है।

extra में वे सभी packages हैं जो core में fit नहीं होते। इस repository को Package Maintainers और Arch Developers द्वारा jointly maintain किया जाता है। उदाहरण: Xorg, window managers, web browsers, media players, Python और Ruby जैसी languages के साथ काम करने के tools, और बहुत कुछ।

multilib

यह repository आपके पसंदीदा mirror पर .../multilib/os/ में मिल सकती है।

multilib में 32-bit software और libraries हैं जिनका उपयोग 64-bit installs पर 32-bit applications को run और build करने के लिए किया जा सकता है (जैसे Steam, आदि)।

multilib repository enable होने पर, 32-bit compatible libraries /usr/lib32/ के अंदर स्थित होती हैं।

Multilib enable करना

multilib repository को enable करने के लिए, /etc/pacman.conf में [multilib] section को uncomment करें:

/etc/pacman.conf

[multilib]
Include = /etc/pacman.d/mirrorlist

फिर system को upgrade करें और desired multilib packages install करें।

Tip multilib repository में सभी packages को list करने के लिए pacman -Sl multilib run करें। 32-bit library package names lib32- से शुरू होते हैं।

Multilib disable करना

multilib से install किए गए सभी packages को remove करने के लिए निम्नलिखित command execute करें:

# pacman -R $(comm -12 <(pacman -Qq | sort) <(pacman -Slq multilib | sort))

अगर आपको gcc-libs के साथ conflicts हैं तो gcc-libs package और base-devel package की dependencies को reinstall करें (देखें Pacman/Tips and tricks)।

Note अगर command error: no targets specified (use -h for help) return करता है तो इसका मतलब है कि आपके system पर multilib repository से कोई packages install नहीं हैं।

/etc/pacman.conf में [multilib] section को comment out करें:

/etc/pacman.conf

#[multilib]
#Include = /etc/pacman.d/mirrorlist

फिर system को upgrade करें।

Testing repositories

Testing repositories का intended purpose यह है कि main repositories में acceptance से पहले packages के लिए एक staging area प्रदान किया जाए। Package maintainers (और सामान्य users) फिर इन testing packages को access कर सकते हैं यह सुनिश्चित करने के लिए कि नए package को integrate करने में कोई समस्याएं नहीं हैं। एक बार package test हो जाने और कोई errors नहीं मिलने पर, package को फिर primary repositories में move किया जा सकता है।

कौन से packages testing में जाते हैं?

निम्नलिखित decision tree देखें:

क्या package core repository के लिए है?
  ├─ हाँ → core-testing में जाना अनिवार्य
  └─ नहीं → क्या package बहुत सारे packages को affect करता है? (जैसे perl, python)
      ├─ हाँ → testing repository में जाना चाहिए
      └─ नहीं → क्या package से कुछ break होने की उम्मीद है?
          ├─ हाँ → testing repository में जाना चाहिए
          └─ नहीं → सीधे stable repository में जा सकता है

सभी packages को इस testing process से गुजरने की जरूरत नहीं है। नए packages testing repository में जाते हैं अगर:

वे core repository के लिए destined हैं। core में हर चीज को core-testing से गुजरना होता है।
उनसे update पर कुछ break होने की उम्मीद है और पहले test करने की जरूरत है।
वे कई packages को affect करते हैं (जैसे perl या python)।
वे किसी Junior Package Maintainer द्वारा build किए गए हैं।

Testing repositories का उपयोग आमतौर पर packages के बड़े collections की नई releases के लिए भी किया जाता है जैसे GNOME और KDE।

Testing repositories के बीच संबंध

Testing repositories को enable करते समय dependencies को ध्यान में रखें:

Repository Dependencies:
┌─────────────────┐
│ core-testing    │ ←┐
└─────────────────┘  │
         ↕           │ दोनों को साथ में enable करना जरूरी
┌─────────────────┐  │
│ extra-testing   │ ←┘
└─────────────────┘
         ↕
┌─────────────────┐
│ multilib-testing│ → ऊपर की दोनों testing repos पर निर्भर
└─────────────────┘

┌─────────────────┐
│ gnome-unstable  │ → सभी testing repos के साथ use करें
└─────────────────┘

┌─────────────────┐
│ kde-unstable    │ → सभी testing repos के साथ use करें
└─────────────────┘

Note Testing repositories "newest of the new" package versions के लिए नहीं हैं। उनके purpose का एक हिस्सा उन package updates को hold करना है जो system को break करने की क्षमता रखते हैं, या तो core set of packages का हिस्सा होने के कारण, या अन्य तरीकों से critical होने के कारण। इस तरह, testing repositories के users को strongly encourage किया जाता है कि वे arch-dev-public mailing list को subscribe करें, testing repositories forum को watch करें, और सभी bugs report करें। आपको Arch Testing Team में join करने पर भी विचार करना चाहिए।

Warning

Testing repositories में pre-release software versions हो सकते हैं।
Testing repositories को enable करते समय सावधान रहें। Update perform करने के बाद आपका system break हो सकता है। केवल experienced users जो potential system breakage से deal करना जानते हैं उन्हें इसका उपयोग करना चाहिए।
अगर आप core-testing enable करते हैं, तो आपको extra-testing भी enable करना होगा, और vice versa। अगर आप निम्नलिखित subsections में listed कोई अन्य testing repository enable करते हैं, तो आपको core-testing और extra-testing दोनों भी enable करने होंगे।
चूंकि main repositories में सभी packages के testing repositories में versions नहीं होते, core और extra main repositories को retain किया जाना चाहिए, और corresponding testing repositories को main repository के सामने होना चाहिए।

core-testing

यह repository आपके पसंदीदा mirror पर .../core-testing/os/ में मिल सकती है।

core-testing में वे packages हैं जो core repository के candidates हैं।

core-testing एकमात्र repository है जिसमें किसी भी अन्य official repositories के साथ name collisions हो सकती हैं। अगर enabled है, तो इसे आपकी /etc/pacman.conf file में पहली listed repository होना चाहिए।

extra-testing

यह repository core-testing repository के समान है, लेकिन उन packages के लिए जो extra repository के candidates हैं।

multilib-testing

यह repository core-testing repository के समान है, लेकिन उन packages के लिए जो multilib repository के candidates हैं।

gnome-unstable

इस repository में GNOME desktop environment के pre-releases (Alpha, Beta, RC) के साथ-साथ stable versions के लिए testing packages हैं, इनके main extra-testing repository में transition से पहले।

इसे enable करने के लिए, /etc/pacman.conf में निम्नलिखित lines add करें:

/etc/pacman.conf

[gnome-unstable]
Include = /etc/pacman.d/mirrorlist

gnome-unstable entry repositories की list में top पर होनी चाहिए (यानी, enabled core-testing entry के ऊपर; ऊपर warnings देखें)।

कृपया packaging से संबंधित bugs को Arch's GitLab में report करें, जबकि बाकी सब कुछ upstream GNOME GitLab को report किया जाना चाहिए।

इस repository के संबंध में अतिरिक्त सहायता और जानकारी के लिए, कृपया Matrix Group में join करें।

kde-unstable

इस repository में KDE Plasma और Applications का latest beta या Release Candidate है।

इसे enable करने के लिए, /etc/pacman.conf में निम्नलिखित lines add करें:

/etc/pacman.conf

[kde-unstable]
Include = /etc/pacman.d/mirrorlist

kde-unstable entry repositories की list में top पर होनी चाहिए (यानी, enabled core-testing entry के ऊपर; ऊपर warnings देखें)।

सुनिश्चित करें कि अगर आपको कोई समस्या मिलती है तो आप bug reports बनाएं।

Testing repositories disable करना

अगर आपने testing repositories enable की थीं, लेकिन बाद में उन्हें disable करने का फैसला किया, तो आपको चाहिए:

उन्हें /etc/pacman.conf से remove (comment out) करें
इन repositories से अपने updates को "rollback" करने के लिए pacman -Syuu perform करें।

दूसरा item optional है, लेकिन अगर आपको कोई समस्या दिखाई देती है तो इसे ध्यान में रखें।

Staging repositories

Warning किसी भी कारण से staging repositories को enable न करें। Update perform करने के बाद आपका system निस्संदेह break हो जाएगा। यह repository केवल backend developer use के लिए है।

इस repository में broken packages हैं और इसका उपयोग केवल developers द्वारा एक साथ कई packages के rebuilds के दौरान किया जाता है। उन packages को rebuild करने के लिए जो उदाहरण के लिए, एक नई shared library पर depend करते हैं, shared library को पहले build और staging repositories में upload किया जाना चाहिए ताकि अन्य developers के लिए available हो सके। जैसे ही सभी dependent packages rebuild हो जाते हैं, packages के group को फिर testing या main repositories में move किया जाता है, जो भी अधिक appropriate हो।

Staging repositories के introduction की अधिक historical details के लिए announcement देखें।

Historical background

अधिकांश repository splits ऐतिहासिक कारणों से हैं। मूल रूप से, जब Arch Linux बहुत कम users द्वारा उपयोग किया जाता था, केवल एक repository थी जिसे official (अब core) के नाम से जाना जाता था। उस समय, official में मूल रूप से Judd Vinet के पसंदीदा applications होते थे। इसे हर "type" के program में से एक contain करने के लिए designed किया गया था — एक DE, एक major browser, आदि।

उस समय ऐसे users थे जो Judd की selection पसंद नहीं करते थे, इसलिए चूंकि Arch build system उपयोग करने में बहुत आसान है, उन्होंने अपने खुद के packages बनाए। ये packages unofficial नामक repository में गए, और Judd के अलावा अन्य developers द्वारा maintain किए गए। आखिरकार, दोनों repositories को developers द्वारा समान रूप से supported माना गया, इसलिए official और unofficial नाम अब उनके वास्तविक purpose को reflect नहीं करते थे। बाद में version 0.5 release के आसपास उन्हें current और extra में rename कर दिया गया।

2007.8.1 release के तुरंत बाद, current को core में rename कर दिया गया ताकि इसमें वास्तव में क्या है इस बारे में confusion को रोका जा सके। Repositories अब developers और community की नजर में कम या ज्यादा equal हैं, लेकिन core में कुछ अंतर हैं। मुख्य distinction यह है कि Installation CDs और release snapshots के लिए उपयोग किए जाने वाले packages केवल core से लिए जाते हैं। यह repository अभी भी एक complete Linux system देती है, हालांकि यह वह Linux system नहीं हो सकता जो आप चाहते हैं।

0.5/0.6 के आसपास कुछ समय में, बहुत सारे packages थे जिन्हें developers maintain नहीं करना चाहते थे। Jason Chu ने "Trusted User Repositories" set up की, जो unofficial repositories थीं जिनमें trusted users अपने द्वारा बनाए गए packages रख सकते थे। एक staging repository थी जहां packages को Arch Linux developers में से एक द्वारा official repositories में promote किया जा सकता था, लेकिन इसके अलावा, developers और trusted users कम या ज्यादा अलग थे।

यह कुछ समय के लिए काम करता रहा, लेकिन तब नहीं जब trusted users अपनी repositories से ऊब गए, और तब नहीं जब अन्य users अपने खुद के packages share करना चाहते थे। इससे AUR का विकास हुआ। Trusted Users को एक अधिक closely knit group में conglomerated किया गया, और अब वे collectively community repository को maintain करते थे। TUs अभी भी Arch Linux developers से एक अलग group थे, और उनके बीच बहुत अधिक communication नहीं था। हालांकि, popular packages को अभी भी कभी-कभार community से extra में promote किया जाता था। AUR सभी users को PKGBUILDs submit करने की भी अनुमति देता है।

core में एक kernel ने कई user systems को break करने के बाद, "core signoff policy" introduce की गई। तब से, core के लिए सभी package updates को पहले core-testing repository से गुजरना पड़ता है, और केवल अन्य developers या Arch Testing Team के लोगों से multiple signoffs के बाद ही move करने की अनुमति होती है। समय के साथ, यह देखा गया कि विभिन्न core packages का कम usage था, और user signoffs या यहां तक कि bug reports की कमी को ऐसे packages को accept करने के criteria के रूप में अनौपचारिक रूप से accepted किया गया।

2009/2010 की शुरुआत के अंत में, कुछ नए filesystems के आगमन और installation के दौरान उनका support करने की इच्छा के साथ, साथ ही यह एहसास कि core को कभी स्पष्ट रूप से defined नहीं किया गया था (बस "महत्वपूर्ण packages, developers द्वारा handpicked"), repository को एक अधिक सटीक description मिला।

This article or section needs expansion.

Reason: 2010 से 2023 तक का history absent है: यह document किया जाना चाहिए कि हम "Trusted Users अभी भी Arch Linux developers से एक अलग group हैं, और उनके बीच बहुत अधिक communication नहीं है" से उन्हें distribution का एक पूर्ण हिस्सा माने जाने तक कैसे पहुंचे। (Discuss in Talk:Official repositories (हिन्दी))

2021 में शुरू होकर, और 2023 के अंत में finalize होकर, "Trusted Users" को "Package Maintainers" में rename कर दिया गया।

2023 में वर्षों के पूर्व काम के बाद distribution ने अपनी back-end services को git में migrate किया और उसी समय एक नए repository layout में भी switch किया। नए layout में extra में वे सभी packages होंगे जो पहले community में थे और testing repositories को testing से core-testing और extra-testing में split किया गया, community-testing को पूरी तरह से हटा दिया गया। उस समय से Package Maintainers नए packages को extra में push करने में भी सक्षम थे।