Official repositories (हिन्दी)

Related articles
Arch build system
Arch User Repository
makepkg
Mirrors
Official repositories web interface
pacman
PKGBUILD
Unofficial user 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 करने में भी सक्षम थे।