Duplicate apt sources error को कैसे ठीक करें

Duplicate apt sources error का क्या अर्थ है

Duplicate apt sources का अर्थ है कि एक ही repository को दो बार घोषित किया गया है, दो अलग-अलग फाइलों में, और APT (advanced package tool) को दोनों प्रतियां मिल गई हैं। Ubuntu 24.04 और उसके बाद के वर्ज़न पर ऐसा लगभग हमेशा इसलिए होता है क्योंकि किसी थर्ड-पार्टी इंस्टाल स्क्रिप्ट ने एक पुरानी एक-लाइन वाली .list फाइल लिख दी है, जबकि उसी repository के लिए एक deb822 .sources फाइल पहले से ही डिस्क पर मौजूद थी। कुछ भी करप्ट नहीं है और कोई भी पैकेज खतरे में नहीं है। दो घोषणाओं में से एक को हटा दें और संदेश गायब हो जाएगा।

यह वह लाइन है जिसे लोग सर्च बॉक्स में पेस्ट करते हैं:

W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/docker.list:1 and /etc/apt/sources.list.d/docker.sources:1

इसे अंत से पढ़ें। दो फाइलें, प्रत्येक एक लाइन नंबर के साथ, एक ही बात घोषित करती हैं। Target Packages वह इंडेक्स है जिसे apt यह जानने के लिए डाउनलोड करता है कि कोई repository कौन से पैकेज प्रदान करती है, और stable/binary-amd64/Packages उस घटक (stable) और आर्किटेक्चर (amd64) का नाम बताता है जिसे वह इंडेक्स कवर करता है। इसलिए apt आपको बता रहा है कि stable घटक के लिए amd64 इंडेक्स docker.list में लाइन 1 पर कॉन्फ़िगर किया गया है, और फिर से docker.sources में लाइन 1 पर।

apt 3.0 और उसके बाद के वर्ज़न पर, जिसका अर्थ है Ubuntu 25.04 और उसके बाद, और Debian 13, वही संदेश W: के बजाय Warning: से शुरू होता है। प्रीफिक्स के बाद का टेक्स्ट समान है।

वह चेतावनी हल्का मामला है। apt दोनों घोषणाओं को मर्ज कर देता है और अपडेट अभी भी चलता है, क्योंकि दोनों एक ही आर्काइव का वर्णन एक ही की (key) के साथ करते हैं। कठिन मामला सब कुछ रोक देता है:

E: Conflicting values set for option Signed-By regarding source https://download.docker.com/linux/ubuntu/ noble: /usr/share/keyrings/docker-archive-keyring.gpg != /etc/apt/keyrings/docker.asc
E: The list of sources could not be read.

apt यहाँ मना कर देता है क्योंकि दो घोषणाएं एक आर्काइव के लिए अलग-अलग साइनिंग की (signing keys) का नाम लेती हैं। यह दो समान घोषणाओं को मर्ज कर देगा, लेकिन यह दो Signed-By मानों के बीच चयन नहीं करेगा, क्योंकि गलत को चुनने का मतलब है पैकेज हस्ताक्षरों की जांच उस की (key) के खिलाफ करना जिससे आर्काइव मालिक ने कभी साइन नहीं किया था। इसलिए apt किसी भी सोर्स को नहीं पढ़ता है। apt update और apt install दोनों उन दो लाइनों के साथ विफल हो जाते हैं जब तक कि आप फाइलों को मैन्युअल रूप से संपादित नहीं करते।

डुप्लीकेट कैसे बनता है

ये दोनों फॉर्मेट अलग-अलग एक्सटेंशन वाली फाइलों में मौजूद होते हैं, इसलिए डिस्क पर ऐसा कुछ नहीं है जो दोनों को एक साथ रहने से रोके। apt को इस ओवरलैप का पता तब चलता है जब वह हर सोर्स फाइल को उन इंडेक्स टारगेट्स की सूची में विस्तारित करता है जिन्हें वह फेच (fetch) करना चाहता है। उस क्षण तक docker.list और docker.sources दो असंबंधित फाइलें होती हैं।

चार सामान्य घटनाएं इस जोड़ी को बनाती हैं:

• एक वेंडर इंस्टॉल स्क्रिप्ट, या किसी पुरानी पोस्ट से कॉपी किया गया कमांड, /etc/apt/sources.list.d/vendor.list को एक tee लाइन के साथ लिखता है।
• वेंडर का अपना पैकेज बाद में /etc/apt/sources.list.d/vendor.sources शिप करता है और उसे आपके लिए इंस्टॉल कर देता है।
• Ubuntu 24.04 और उसके बाद के वर्ज़न पर add-apt-repository deb822 .sources फाइलें लिखता है, इसलिए एक PPA (personal package archive) जिसे आपने कभी हाथ से .list के रूप में जोड़ा था, वह .sources के रूप में वापस आ जाता है।
• एक रिलीज अपग्रेड ने डिस्ट्रीब्यूशन के अपने सोर्सेज को deb822 में फिर से लिखा और आपकी हाथ से लिखी हुई .list फाइल को उनके बगल में बिना छुए छोड़ दिया।

हर रास्ता अपने आप में उचित है। डुप्लीकेट तब बनता है जब इनमें से दो घटनाएं एक ही बॉक्स पर, अक्सर महीनों के अंतराल पर, घटित होती हैं।

दो प्रारूप, साथ-साथ

पुराना प्रारूप प्रति रिपॉजिटरी एक पंक्ति का है, और इसका प्रत्येक भाग स्थिति-आधारित (positional) है।

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable

क्रम निश्चित है: प्रकार (binary पैकेजों के लिए deb, source पैकेजों के लिए deb-src), फिर वर्गाकार कोष्ठक में विकल्प, फिर आर्काइव का URI (uniform resource identifier), फिर suite, और अंत में एक या अधिक components। चूंकि अर्थ स्थिति से निर्धारित होता है, इसलिए गलत जगह पर एक space होने से apt द्वारा पढ़ा जाने वाला अर्थ बदल जाता है।

deb822 उन्हीं बातों को नामित fields के एक stanza के रूप में प्रस्तुत करता है। यह नाम RFC 822 से आया है, जो कि mail header की वह शैली है जिसका उपयोग Debian पहले से ही package control फाइलों के लिए करता है।

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

वही रिपॉजिटरी, वही key, कुछ भी नया नहीं जोड़ा गया। मैपिंग सीधी है: deb बदलकर Types हो जाता है, आर्काइव का पता URIs बन जाता है, suite Suites बन जाता है, components Components बन जाते हैं, और प्रत्येक कोष्ठक वाला विकल्प अपना स्वयं का field बन जाता है, इसलिए signed-by= बदलकर Signed-By: हो जाता है और arch= बदलकर Architectures: हो जाता है।

प्रत्येक field का नाम बहुवचन (plural) है क्योंकि प्रत्येक field space से अलग की गई सूची स्वीकार करता है। एक stanza में Suites: noble noble-updates noble-backports तीन अलग-अलग deb पंक्तियों की जगह ले लेता है। एक खाली पंक्ति stanza को समाप्त करती है, इसलिए एक एकल .sources फाइल में कई रिपॉजिटरी हो सकती हैं। deb822 उन सेटिंग्स को भी संभालता है जिन्हें एक-पंक्ति प्रारूप ठीक से नहीं कर पाता: रिपॉजिटरी को बंद करने के लिए Enabled: no, Trusted, Check-Valid-Until, और सीधे Signed-By में पेस्ट की गई एक इनलाइन key, जिसमें प्रत्येक पंक्ति एक space से indented होती है और खाली पंक्तियों को एक बिंदु (dot) के रूप में लिखा जाता है।

प्रत्येक फ़ाइल कहाँ स्थित होती है

• /etc/apt/sources.list: मूल एकल फ़ाइल। Ubuntu 24.04 और उसके नए वर्ज़न पर यह आमतौर पर खाली होती है या इसमें केवल एक टिप्पणी होती है जो नए स्थान की ओर इशारा करती है।
• /etc/apt/sources.list.d/*.list: एक-पंक्ति वाली प्रविष्टियाँ, सामान्यतः प्रति रिपॉजिटरी एक फ़ाइल।
• /etc/apt/sources.list.d/*.sources: deb822 स्टैंज़ा। Ubuntu 24.04 और उसके नए वर्ज़न वितरण की अपनी रिपॉजिटरी को यहाँ, ubuntu.sources में रखते हैं।
• /etc/apt/keyrings/: जहाँ आपके द्वारा जोड़ी गई कुंजियाँ (keys) रहती हैं। /usr/share/keyrings/ में वे कुंजियाँ होती हैं जो किसी पैकेज के साथ आती हैं।

apt केवल उन फ़ाइलों को पढ़ता है जो .list या .sources पर समाप्त होती हैं, और फ़ाइल नाम में अक्षर, अंक, अंडरस्कोर, हाइफ़न और पीरियड हो सकते हैं। किसी अन्य एक्सटेंशन वाली फ़ाइल को एक सूचना के साथ छोड़ दिया जाता है, जो नीचे दिए गए सुधार के लिए महत्वपूर्ण है।

डुप्लिकेट पेयर ढूँढें

डायरेक्टरी लिस्टिंग से शुरुआत करें:

ls -l /etc/apt/sources.list.d/

-rw-r--r-- 1 root root  195 Aug  3 09:12 docker.list
-rw-r--r-- 1 root root  254 Aug  9 14:40 docker.sources
-rw-r--r-- 1 root root 2683 Jun 11 08:02 ubuntu.sources

एक ही नाम (stem) और अलग एक्सटेंशन वाली दो फाइलें आमतौर पर एक पेयर होती हैं, लेकिन नामों पर भरोसा न करें। सामग्री को पढ़ें, क्योंकि एक डुप्लिकेट किसी भी नाम की फाइल में छिपा हो सकता है:

grep -rn -E '^(deb |deb-src |Types:|URIs:|Suites:|Signed-By:)' /etc/apt/sources.list /etc/apt/sources.list.d/

/etc/apt/sources.list.d/docker.list:1:deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu noble stable
/etc/apt/sources.list.d/docker.sources:1:Types: deb
/etc/apt/sources.list.d/docker.sources:2:URIs: https://download.docker.com/linux/ubuntu
/etc/apt/sources.list.d/docker.sources:3:Suites: noble
/etc/apt/sources.list.d/docker.sources:6:Signed-By: /etc/apt/keyrings/docker.asc

यह पेयर वे दो एंट्री हैं जिनमें एक ही host और एक ही suite है। दोनों https://download.docker.com/linux/ubuntu और suite noble की ओर इशारा करती हैं, इसलिए वे एक ही रिपॉजिटरी हैं जो दो बार लिखी गई हैं। उनके Signed-By पाथ भी अलग हैं, जो पहले दिखाए गए Conflicting values एरर का कारण बनते हैं।

इस चरण के लिए apt कमांड के बजाय grep का उपयोग करें। जब apt पहले से ही कॉन्फ्लिक्ट के कारण रुक रहा हो, तो वह आपकी सोर्स लिस्ट भी नहीं दिखा सकता, इसलिए apt-cache policy आपके इच्छित उत्तर के बजाय वही एरर प्रिंट करता है।

इसे ठीक करें: deb822 फ़ाइल रखें, पुरानी फ़ाइल हटा दें

.sources फ़ाइल को बनाए रखें। यह वह प्रारूप है जिसमें apt टूलिंग अब लिखती है, और यही वह दिशा है जिसमें Debian और Ubuntu दोनों आगे बढ़ रहे हैं। कुछ भी हटाने से पहले, जाँचें कि डिस्क पर दो key paths में से कौन सा मौजूद है:

ls -l /etc/apt/keyrings/ /usr/share/keyrings/ | grep -i docker

-rw-r--r-- 1 root root 4813 Aug  9 14:40 docker.asc

केवल /etc/apt/keyrings/docker.asc मौजूद है, इसलिए deb822 फ़ाइल ही सही जानकारी दे रही है और .list फ़ाइल एक ऐसी key की ओर इशारा करती है जिसे हटा दिया गया है। यदि ऐसा पता चलता है कि जिस फ़ाइल को आप रखना चाहते हैं, उसमें गायब key का नाम है, तो पहले उसमें working path को कॉपी करें, फिर दूसरी फ़ाइल को हटा दें।

पुरानी फ़ाइल को सीधे हटाने के बजाय उसे डायरेक्टरी से बाहर ले जाएँ:

sudo mkdir -p /root/apt-sources-backup
sudo mv /etc/apt/sources.list.d/docker.list /root/apt-sources-backup/
sudo apt update

इसे docker.list.bak पर रीनेम करके वहीं छोड़ देना भी काम करता है, क्योंकि apt अज्ञात एक्सटेंशन को अनदेखा कर देता है, लेकिन फिर हर apt रन यह प्रिंट करता है:

N: Ignoring file 'docker.list.bak' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension

फ़ाइल को कहीं और ले जाने से वह सूचना आपकी स्क्रीन पर नहीं आती और बैकअप भी सुरक्षित रहता है। इसके बाद एक स्वस्थ apt update ऐसा दिखता है, जिसमें कोई भी लाइन दो फ़ाइलों का नाम नहीं लेती:

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 https://download.docker.com/linux/ubuntu noble InRelease [48.8 kB]
Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Fetched 175 kB in 1s (146 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

अब पुष्टि करें कि रिपॉजिटरी संपादन के बाद भी सुरक्षित है:

apt-cache policy | grep download.docker.com

 500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
     origin download.docker.com

यदि किसी वेंडर का डॉक्यूमेंटेशन अभी भी वन-लाइन फ़ाइल का उपयोग करता है, तो आप उसे रख सकते हैं और इसके बजाय .sources फ़ाइल को हटा सकते हैं। एक नियम इसे किसी भी तरह से तय करता है: किसी दिए गए आर्काइव और सुइट के लिए केवल एक ही फ़ाइल घोषित की जा सकती है।

एक खराब third-party source के कारण apt update क्यों रुक जाता है

पड़ोसी विफलता अलग दिखती है लेकिन इसका मूल कारण वही है, एक ऐसा third-party source जिसे apt उपयोग नहीं कर सकता। पहला संस्करण एक missing key है:

Err:5 https://download.docker.com/linux/ubuntu noble InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8
E: The repository 'https://download.docker.com/linux/ubuntu noble InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Signed-By फ़ील्ड गायब है, या यह ऐसी फ़ाइल की ओर इशारा करती है जो उपयोग करने योग्य key नहीं है, इसलिए apt आर्काइव की InRelease फ़ाइल पर हस्ताक्षर (signature) को सत्यापित नहीं कर सकता। इसके बाद यह पूरे रिपॉजिटरी को हटा देता है बजाय इसके कि उन पैकेज सूचियों पर भरोसा करे जिन्हें वह जाँच नहीं सकता। स्वयं key फ़ाइल को देखें:

ls -l /etc/apt/keyrings/docker.asc
gpg --show-keys /etc/apt/keyrings/docker.asc

एक कार्यशील key एक pub लाइन को key id के साथ और एक uid लाइन को वेंडर के नाम के साथ प्रिंट करती है। gpg: no valid OpenPGP data found. का अर्थ है कि फ़ाइल बिल्कुल भी key नहीं है, जिसका आमतौर पर मतलब है कि डाउनलोड ने एक error पेज सेव कर लिया है क्योंकि key URL बदल गया है। key को फिर से प्राप्त करें, फ़ाइल की जाँच करें, और फिर apt update चलाएँ।

दूसरा संस्करण release upgrade के बाद आता है:

Err:6 https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky InRelease
  404  Not Found [IP: 10.0.0.80 443]
E: The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky Release' does not have a Release file.

PPA ने उस suite के लिए कुछ भी प्रकाशित नहीं किया है, इसलिए सर्वर पर वह path मौजूद नहीं है और अनुरोध 404 लौटाता है। आपके अन्य रिपॉजिटरी अभी भी अपडेट होते हैं, और जो पैकेज आपके पास पहले से हैं वे अप्रभावित रहते हैं। हालाँकि, रन non-zero exit देता है, इसलिए कोई भी स्क्रिप्ट जो apt update की exit status की जाँच करती है, अब हर बार चलने पर विफलता की रिपोर्ट करती है। यही कारण है कि unattended security upgrades कॉन्फ़िगर किए गए बॉक्स पर एक मृत source को हटाना उचित है: दैनिक शोर (noise) में ही वास्तविक विफलता छिपी होती है।

बाकी को प्रभावित किए बिना एक source को disable करना

deb822 फाइल के लिए, stanza में एक field जोड़ें और उसे save करें:

Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu
Suites: plucky
Components: main
Signed-By: /etc/apt/keyrings/ondrej-php.asc
Enabled: no

apt manual stanza की प्रत्येक line को comment out करने के बजाय इस तरीके की सिफारिश करता है, और इसे undo करना भी आसान है। एक line वाली फाइल के लिए, line की शुरुआत में # लगाएँ। दोनों format के लिए, फाइल को /etc/apt/sources.list.d/ से बाहर ले जाना भी काम करता है, और जब repository हमेशा के लिए हटानी हो तो यही विकल्प चुनें।

sudo apt update को फिर से चलाएँ। उस repository के लिए Err: ब्लॉक गायब हो जाता है, और exit status 0 पर वापस आ जाता है, जिसे आप अगली line पर echo $? के साथ check कर सकते हैं।

किसी broken source को कभी भी sudo rm /etc/apt/sources.list.d/* से ठीक न करें। Ubuntu 24.04 और उसके बाद के versions पर यह ubuntu.sources को delete कर देता है, जिसमें distribution की अपनी repositories होती हैं, इसलिए apt के पास कोई package list नहीं बचती और वह उन software के लिए E: Unable to locate package curl रिपोर्ट करता है जो स्पष्ट रूप से मौजूद होते हैं। यदि आप इसे पहले ही चला चुके हैं, तो फाइल को वापस लिखें:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

इसे /etc/apt/sources.list.d/ubuntu.sources के रूप में save करें, जिसमें noble की जगह lsb_release -cs से अपना release name लिखें, और फिर sudo apt update चलाएँ।

legacy .list फाइलों को deb822 में बदलें

अगस्त 2026 से, apt 3.0 और उसके बाद के संस्करणों में इसके लिए एक कनवर्टर उपलब्ध है। Debian 13, Ubuntu 25.04 और उसके बाद के सभी releases (26.04 सहित) में यह सुविधा मौजूद है। संस्करण की जाँच करें, फिर इसे चलाएँ:

apt --version
sudo apt modernize-sources

यह /etc/apt/sources.list.d/ के अंतर्गत मौजूद एक-पंक्ति वाली फाइलों को deb822 .sources फाइलों में फिर से लिखता है। इसके आउटपुट को पढ़ें, फिर स्वयं डायरेक्टरी को लिस्ट करें और परिणामों पर भरोसा करने से पहले apt update चलाएँ। Ubuntu 24.04 में पुराना apt संस्करण है जिसमें ऐसा कोई subcommand नहीं है, और वहां यह कमांड E: Invalid operation modernize-sources का उत्तर देता है। उस release पर, ऊपर दिए गए field mapping का उपयोग करके मैन्युअल रूप से रूपांतरण करें।

रूपांतरण करना आज के समय में वैकल्पिक है, क्योंकि apt अभी भी दोनों प्रारूपों को पढ़ता है। जिस सर्वर को आप लंबे समय तक बनाए रखना चाहते हैं, उस पर ऐसा करना उचित है, क्योंकि अब sources लिखने वाले सभी टूल्स deb822 का उपयोग करते हैं। जिस सिस्टम में केवल .sources फाइलें होंगी, उसमें इस प्रकार की डुप्लीकेट फाइलें नहीं बनेंगी।

सर्वर पर थर्ड-पार्टी सोर्सेज को व्यवस्थित रखें

थर्ड-पार्टी रिपॉजिटरीज सर्वर का वह हिस्सा हैं जो सबसे जल्दी पुराना पड़ता है। प्रत्येक रिपॉजिटरी किसी अन्य व्यक्ति द्वारा आपके Ubuntu रिलीज के लिए पैकेज पब्लिश करते रहने का एक वादा है, और एक रिलीज अपग्रेड उसी दोपहर उन सभी वादों की परीक्षा ले लेता है।

• थर्ड-पार्टी रिपॉजिटरी तभी जोड़ें जब डिस्ट्रीब्यूशन पैकेज से काम न चल रहा हो। एक साधारण LAMP stack on Ubuntu 24.04 को किसी की आवश्यकता नहीं होती: Ubuntu आर्काइव में वे सभी पैकेज मौजूद होते हैं जिनका वह उपयोग करता है, और रिलीज के पूरे जीवनकाल के लिए सुरक्षा अपडेट भी मिलते हैं।
• कीज (keys) को /etc/apt/keyrings/ में रखें, प्रति वेंडर एक फाइल, मोड 644 के साथ। अनप्रिविलेज्ड _apt यूजर डाउनलोडिंग का काम करता है और उसे की पढ़नी होती है, इसलिए केवल root द्वारा पढ़ी जा सकने वाली की फाइल उस रिपॉजिटरी से हर फेच (fetch) पर परमिशन एरर देती है।
• हर स्टैंजा (stanza) में Signed-By को उस सटीक फाइल पर पॉइंट करें। /etc/apt/trusted.gpg या /etc/apt/trusted.gpg.d/ में रखी गई की बॉक्स पर मौजूद हर रिपॉजिटरी के लिए ट्रस्टेड होती है, जिसका अर्थ है कि वर्षों पहले जोड़ी गई कोई वेंडर की कहीं से भी आए पैकेजों को वैलिडेट कर सकती है।
• रिलीज अपग्रेड से पहले, अपने सोर्सेज को पढ़ें और जांचें कि क्या प्रत्येक वेंडर उस सुइट के लिए पहले से पब्लिश कर रहा है जिस पर आप शिफ्ट हो रहे हैं।

पुराने ग्लोबल कीरिंग में मौजूद एक की हर अपडेट पर खुद को सूचित करती है:

W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

उस एक की को उसकी अपनी फाइल में एक्सपोर्ट करें, फिर स्टैंजा को उस पर पॉइंट करें:

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export 7EA0A9C3F273FCD8 | sudo tee /etc/apt/keyrings/docker.gpg > /dev/null
sudo chmod 644 /etc/apt/keyrings/docker.gpg

रिपॉजिटरी के स्टैंजा में Signed-By: /etc/apt/keyrings/docker.gpg जोड़ें और sudo apt update चलाएं। जब कोई रिपॉजिटरी पुराने कीरिंग पर निर्भर नहीं रहती, तो चेतावनी बंद हो जाती है, और फिर आप sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 के साथ उस एंट्री को हटा सकते हैं।

एक और आदत सबसे अधिक परेशानी से बचाती है। do-release-upgrade अपग्रेड के लिए थर्ड-पार्टी सोर्सेज को डिसेबल कर देता है और बाद में उन्हें बंद ही रहने देता है, और उन्हें एक-एक करके मैन्युअल रूप से वापस चालू करना ही वह जगह है जहाँ डुप्लीकेट डिक्लेरेशन बन जाते हैं। शुरू करने से पहले the Ubuntu 24.04 to 26.04 upgrade guide पढ़ें, और लिख लें कि आपको किन रिपॉजिटरीज की अभी भी आवश्यकता है। जिस मशीन को आपने अभी-अभी बनाया है, उस पर सोर्सेज को सही करने का सबसे सस्ता समय the first ten minutes on a new VPS के दौरान होता है, जब बॉक्स पर केवल वही एंट्रीज होती हैं जो Ubuntu के साथ आई थीं।

FAQ

apt यह क्यों कहता है कि कोई target कई बार कॉन्फ़िगर किया गया है?

क्योंकि /etc/apt/sources.list.d/ के अंतर्गत दो फाइलें एक ही रिपॉजिटरी, सुइट और कंपोनेंट को घोषित करती हैं। यह संदेश दोनों फाइलों के नाम और लाइन नंबर बताता है, जैसे कि docker.list:1 और docker.sources:1। apt इन्हें मर्ज कर देता है और काम जारी रखता है, इसलिए अपडेट की प्रक्रिया काम करती रहती है। फिर भी इस डुप्लीकेट को हटाना बेहतर है: जैसे ही दो फाइलें अलग-अलग साइनिंग की (signing keys) का नाम लेती हैं, apt E: Conflicting values set for option Signed-By के साथ रुक जाता है और किसी भी सोर्स को पढ़ने से मना कर देता है, जिससे apt install भी ब्लॉक हो जाता है।

क्या मुझे .list फाइल रखनी चाहिए या .sources फाइल?

.sources फाइल को रखें। deb822 वह प्रारूप है जिसे Ubuntu 24.04 और नए वर्ज़न पर add-apt-repository लिखता है। इसमें वर्गाकार कोष्ठक (square brackets) में स्थित टेक्स्ट के बजाय प्रत्येक सेटिंग के लिए एक नामित फ़ील्ड होती है, और डिस्ट्रीब्यूशन इसी दिशा में आगे बढ़ रहे हैं। .list फाइल को हटाने से पहले, यह पुष्टि करें कि .sources फाइल के अंदर का Signed-By पाथ एक ऐसी की (key) की ओर इशारा करता है जो मौजूद है, इसके लिए ls -l /etc/apt/keyrings/ का उपयोग करें। पुरानी फाइल को /etc/apt/sources.list.d/ से बाहर ले जाएं, न कि उसे उसी डायरेक्टरी के अंदर रीनेम करें, क्योंकि एक बची हुई .bak फाइल के नाम के कारण apt हर बार एक 'ignored-file' नोटिस प्रिंट करता है।

मैं किसी apt रिपॉजिटरी को हटाए बिना उसे बंद कैसे करूँ?

deb822 .sources फाइल में, स्टैन्ज़ा (stanza) में Enabled: no जोड़ें। एक लाइन वाली .list फाइल में, लाइन की शुरुआत में # लगा दें। किसी भी स्थिति में, बाद में sudo apt update चलाएं और उस रिपॉजिटरी के लिए Err: ब्लॉक गायब हो जाएगा। जब किसी थर्ड-पार्टी रिपॉजिटरी में आपके Ubuntu वर्ज़न के लिए कोई पैकेज न हो और उसका 404 एरर apt update को नॉन-जीरो (non-zero) एग्जिट कोड देने पर मजबूर कर रहा हो, तो यह सही कदम है।

क्या एक लाइन वाला sources.list प्रारूप खत्म हो रहा है?

यह केवल डेप्रिकेटेड (deprecated) है, हटाया नहीं गया है। apt अभी भी .list फाइलों को पढ़ता है और लंबे समय तक पढ़ता रहेगा, इसलिए आपके सर्वर पर कुछ भी कल बंद नहीं होगा। नए टूल deb822 लिखते हैं: Ubuntu 24.04 और नए वर्ज़न डिस्ट्रीब्यूशन रिपॉजिटरी को /etc/apt/sources.list.d/ubuntu.sources में रखते हैं, और add-apt-repository, .sources फाइलें लिखता है। apt 3.0 और नए वर्ज़न पर, sudo apt modernize-sources उन फाइलों को कन्वर्ट कर देता है जो आपके पास अभी भी हैं।