duplicate apt sources त्रुटी कशी दुरुस्त करावी

डुप्लिकेट apt sources त्रुटीचा अर्थ

डुप्लिकेट apt sources म्हणजे एकाच repository ची नोंद दोन वेगवेगळ्या files मध्ये दोनदा केली आहे आणि APT (advanced package tool) ला दोन्ही प्रती सापडल्या आहेत. Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये असे जवळजवळ नेहमी घडते, कारण third-party install script ने जुनी one line .list file लिहिलेली असते आणि त्याच repository साठी deb822 .sources file आधीपासून disk वर असते. काहीही corrupt झालेले नसते आणि कोणत्याही package ला धोका नसतो. दोन declarations पैकी एक delete करा; message दिसणे थांबेल.

लोक search box मध्ये paste करतात ती line:

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

ही line शेवटापासून वाचा. दोन files, प्रत्येकी line number सह, एकाच गोष्टीची declaration करतात. Target Packages हा repository कोणते packages देते हे जाणून घेण्यासाठी apt download करत असलेला index आहे आणि stable/binary-amd64/Packages त्या index मध्ये समाविष्ट component (stable) आणि architecture (amd64) दर्शवते. त्यामुळे apt सांगत आहे की stable component साठीचा amd64 index docker.list मध्ये line 1 वर configured आहे आणि पुन्हा docker.sources मध्ये line 1 वर configured आहे.

apt 3.0 आणि त्यानंतरच्या आवृत्त्यांमध्ये, म्हणजे Ubuntu 25.04 onward आणि Debian 13 मध्ये, हा message W: ऐवजी Warning: ने सुरू होतो. Prefix नंतरचा मजकूर समान असतो.

ही warning सौम्य परिस्थिती दर्शवते. apt दोन्ही declarations merge करते आणि update सुरू राहते, कारण दोन्हीमध्ये समान key सह समान archive वर्णन केलेले असते. कठीण परिस्थितीत पूर्ण प्रक्रिया थांबते:

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 नकार देते, कारण दोन्ही declarations एका archive साठी वेगवेगळ्या signing keys नमूद करतात. दोन identical declarations merge केल्या जातात; परंतु दोन Signed-By values पैकी apt एक निवडत नाही. चुकीची value निवडल्यास package signatures archive मालकाने वापरून sign न केलेल्या key विरुद्ध तपासल्या जातील. त्यामुळे apt कोणतेही sources वाचत नाही. Files हाताने edit करेपर्यंत apt update आणि apt install दोन्ही त्याच दोन lines सह fail होतात.

डुप्लिकेट फाइल तिथे कशी तयार होते

ही दोन्ही स्वरूपे वेगवेगळ्या extensions असलेल्या स्वतंत्र files मध्ये असतात. त्यामुळे disk वर दोन्ही files अस्तित्वात राहण्यास कोणताही अडथळा नसतो. apt प्रत्येक source file चे त्याला fetch करायच्या index targets च्या यादीत रूपांतर करते, तेव्हा उशिरा overlap लक्षात घेतो. तोपर्यंत docker.list आणि docker.sources या दोन असंबंधित files असतात.

चार सामान्य घटनांमुळे ही जोडी तयार होते:

• Vendor install script किंवा जुन्या post मधून copy केलेली command, tee line असलेली /etc/apt/sources.list.d/vendor.list file लिहिते.
• नंतर vendor चे स्वतःचे package /etc/apt/sources.list.d/vendor.sources release करते आणि ते तुमच्यासाठी install करते.
• Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये add-apt-repository deb822 .sources files लिहिते. त्यामुळे तुम्ही पूर्वी manually जोडलेला PPA (personal package archive), .list म्हणून, .sources म्हणून पुन्हा दिसतो.
• Release upgrade ने distribution चे स्वतःचे sources deb822 मध्ये पुन्हा लिहिले, पण तुमची manually लिहिलेली .list file त्यांच्या शेजारी तशीच ठेवली.

प्रत्येक मार्ग स्वतंत्रपणे योग्य आहे. दोन घटना एकाच box वर, अनेकदा काही महिन्यांच्या अंतराने, घडतात तेव्हा duplicate तयार होते.

दोन्ही स्वरूपे, शेजारी शेजारी

जुन्या स्वरूपात प्रत्येक repository साठी एक ओळ असते आणि त्यातील प्रत्येक भाग स्थानानुसार ठरतो.

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

क्रम निश्चित असतो: प्रकार (binary packages साठी deb, source packages साठी deb-src), त्यानंतर चौकोनी कंसातील options, मग archive चा URI (uniform resource identifier), त्यानंतर suite आणि शेवटी एक किंवा अधिक components. अर्थ स्थानावरून ठरत असल्यामुळे चुकीच्या ठिकाणी दिलेली space apt काय वाचते ते बदलू शकते.

deb822 हेच तपशील नामांकित fields असलेल्या stanza च्या स्वरूपात मांडते. या नावाचा उगम RFC 822 मधून झाला आहे. Debian package control files साठी आधीपासून वापरत असलेली mail header शैली RFC 822 मध्ये आहे.

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

तोच repository आणि तीच key; काहीही अतिरिक्त नाही. रूपांतरण थेट आहे: deb चे Types होते, archive address चे URIs होते, suite चे Suites होते, components चे Components होते आणि प्रत्येक bracket option स्वतंत्र field बनतो. त्यामुळे signed-by= चे Signed-By: आणि arch= चे Architectures: होते.

प्रत्येक field चे नाव plural असते, कारण प्रत्येक field मध्ये spaces ने विभक्त केलेली list असते. एका stanza मधील Suites: noble noble-updates noble-backports हे तीन स्वतंत्र deb lines ची जागा घेते. Blank line मुळे stanza समाप्त होते. त्यामुळे एका .sources file मध्ये अनेक repositories ठेवता येतात. एका ओळीच्या स्वरूपात हाताळणे कठीण असलेली settings देखील deb822 मध्ये देता येतात: repository बंद करण्यासाठी Enabled: no, Trusted, Check-Valid-Until आणि Signed-By मध्ये थेट paste केलेली inline key. या key मधील प्रत्येक line ला सुरुवातीला एक space indent करावा आणि blank lines एकाच dot ने लिहाव्या.

प्रत्येक फाइलचे स्थान

• /etc/apt/sources.list: मूळ एकमेव फाइल. Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये ही फाइल सहसा रिकामी असते किंवा नवीन स्थानाकडे निर्देश करणारी टिप्पणी असते.
• /etc/apt/sources.list.d/*.list: प्रत्येकी एका ओळीतील नोंदी. सामान्यतः प्रत्येक repository साठी एक फाइल असते.
• /etc/apt/sources.list.d/*.sources: deb822 stanzas. Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये वितरणाच्या स्वतःच्या repositories येथे, ubuntu.sources मध्ये, ठेवल्या जातात.
• /etc/apt/keyrings/: तुम्ही जोडलेल्या keys याच ठिकाणी ठेवाव्यात. /usr/share/keyrings/ मध्ये package मधून आलेल्या keys असतात.

apt फक्त .list किंवा .sources ने समाप्त होणाऱ्या फाइल्स वाचते. फाइलनावात letters, digits, underscore, hyphen आणि period असू शकतात. इतर कोणत्याही extension असलेली फाइल सूचना देऊन वगळली जाते. खालील दुरुस्तीसाठी हे महत्त्वाचे आहे.

डुप्लिकेट जोडी शोधा

सुरुवात directory listing पासून करा:

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 आणि वेगवेगळे extensions असलेल्या दोन files ची जोडी सामान्यतः हीच असते; परंतु names वर विश्वास ठेवू नका. Contents वाचा, कारण duplicate कोणत्याही नावाच्या file मध्ये लपलेली असू शकते:

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 असलेल्या दोन entries ची आहे. दोन्ही https://download.docker.com/linux/ubuntu आणि suite noble कडे निर्देश करतात. त्यामुळे ती एकाच repository ची दोनदा लिहिलेली नोंद आहे. त्यांच्या Signed-By paths मध्येही विसंगती आहे. त्यामुळे आधी दाखवलेली Conflicting values error निर्माण होते.

या टप्प्यासाठी apt command ऐवजी grep वापरा. apt conflict मुळे आधीच थांबत असल्यास ते तुमच्या sources ची list देखील दाखवू शकत नाही. त्यामुळे apt-cache policy तुम्हाला हवे असलेले उत्तर देण्याऐवजी तीच error दाखवते.

दुरुस्ती: deb822 फाइल ठेवा आणि legacy फाइल काढून टाका

.sources फाइल ठेवा. apt tooling आता हाच format लिहिते आणि Debian तसेच Ubuntu याच दिशेने जात आहेत. काहीही हटवण्यापूर्वी खालील दोन महत्त्वाच्या paths पैकी कोणती disk वर अस्तित्वात आहे ते तपासा:

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 कडे निर्देश करते. तुम्ही ठेवणार असलेल्या फाइलमध्ये missing key चे नाव असल्याचे आढळल्यास, आधी कार्यरत path तिच्यात copy करा. त्यानंतर दुसरी फाइल हटवा.

legacy फाइल थेट हटवण्याऐवजी ती directory मधून बाहेर हलवा:

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 अज्ञात extensions दुर्लक्षित करते. मात्र त्यानंतर प्रत्येक apt run वेळी हे दिसते:

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

फाइल दुसरीकडे हलवल्यास हा message दिसत नाही आणि backup देखील जतन राहतो. त्यानंतर योग्य apt update configuration अशी दिसते. त्यात दोन files चे नाव देणारी कोणतीही line नसते:

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.

आता repository edit नंतरही योग्यरीत्या उपलब्ध आहे याची खात्री करा:

apt-cache policy | grep download.docker.com

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

एखाद्या vendor च्या documentation मध्ये अजूनही one-line file गृहीत धरली असल्यास, ती file ठेवून त्याऐवजी .sources फाइल हटवू शकता. दोन्ही बाबतीत एकच नियम लागू होतो: दिलेल्या archive आणि suite ची घोषणा नेमकी एका file मध्येच असावी.

एक तृतीय-पक्ष स्रोत apt update का संपूर्ण काम का ठप्प क्यों करतो

शेजारील अपयश वेगळे दिसते, पण त्याचे मूळ कारण तेच आहे: 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 field नसते किंवा ते usable key नसलेल्या file कडे निर्देश करते. त्यामुळे apt archive च्या InRelease file वरील signature पडताळू शकत नाही. ज्या package lists ची पडताळणी करता येत नाही, त्यांवर विश्वास ठेवण्याऐवजी apt ते संपूर्ण repository नाकारते. Key file स्वतः तपासा:

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

कार्यरत key मध्ये key id असलेली pub line आणि vendor चे नाव असलेली uid line दिसते. gpg: no valid OpenPGP data found. याचा अर्थ file ही key नाही. बहुतेक वेळा key URL बदलल्यामुळे download दरम्यान error page save झाल्याने असे होते. Key पुन्हा fetch करा, file तपासा आणि नंतर 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.

त्या suite साठी PPA ने काहीही publish केलेले नाही. त्यामुळे server वर path अस्तित्वात नसतो आणि request ला 404 मिळतो. तुमची इतर repositories अद्ययावत होत राहतात आणि आधीपासून installed packages वर परिणाम होत नाही. मात्र run चा exit status non-zero राहतो. त्यामुळे apt update चा exit status तपासणारी कोणतीही script प्रत्येक वेळी failure report करते. म्हणून unattended security upgrades configured असलेल्या box वर dead source काढून टाकणे महत्त्वाचे आहे. दररोजच्या output मध्येच खरे failure लपते. Vendor install scripts या दोन्ही प्रकारच्या समस्यांना कारणीभूत ठरू शकतात. म्हणून बहुतेक Ubuntu वरील Tailscale install errors चे कारण script ने न लिहिलेली keyring किंवा archive मध्ये नसलेला release codename हे असते.

एक स्रोत बंद करा आणि उर्वरित स्रोत अबाधित ठेवा

deb822 फाइलसाठी stanza मध्ये एक field जोडा आणि ती जतन करा:

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

प्रत्येक stanza मधील ओळी comment out करण्यापेक्षा ही पद्धत वापरण्याची apt manual मध्ये शिफारस केली आहे. ती पूर्ववत करणेही सोपे आहे. एका ओळीच्या फाइलसाठी ओळीच्या सुरुवातीला # ठेवा. दोन्ही format साठी फाइल /etc/apt/sources.list.d/ मधून बाहेर हलवणेही कार्य करते. Repository कायमची हटवली असल्यास हीच पद्धत वापरा.

पुन्हा sudo apt update चालवा. त्या repository साठीचा Err: block अदृश्य होईल आणि exit status पुन्हा 0 होईल. पुढील ओळीत echo $? वापरून हे तपासा.

तुटलेल्या source चे निराकरण करण्यासाठी कधीही sudo rm /etc/apt/sources.list.d/* वापरू नका. Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये यामुळे ubuntu.sources हटवले जाते. या फाइलमध्ये distribution च्या स्वतःच्या repositories असतात. त्यामुळे apt कडे कोणत्याही package lists शिल्लक राहत नाहीत आणि स्पष्टपणे उपलब्ध असलेल्या 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 म्हणून जतन करा. त्यातील noble च्या जागी lsb_release -cs मधून मिळालेल्या तुमच्या release name चा वापर करा. त्यानंतर sudo apt update चालवा.

लेगसी .list फाइल्स deb822 मध्ये रूपांतरित करा

August 2026 पर्यंत apt 3.0 आणि त्यानंतरच्या आवृत्त्यांमध्ये यासाठी converter उपलब्ध आहे. Debian 13 मध्ये तो उपलब्ध आहे. Ubuntu 25.04 आणि त्यानंतरच्या प्रत्येक release मध्ये, 26.04 सह, तो उपलब्ध आहे. आवृत्ती तपासा आणि नंतर तो चालवा:

apt --version
sudo apt modernize-sources

हा command /etc/apt/sources.list.d/ अंतर्गत असलेल्या one-line files चे deb822 .sources files मध्ये पुनर्लेखन करतो. तो काय output देतो ते वाचा. त्यानंतर directory स्वतः list करा आणि result वर विश्वास ठेवण्यापूर्वी apt update चालवा. Ubuntu 24.04 मध्ये असा subcommand नसलेला जुना apt उपलब्ध आहे. त्या आवृत्तीत command E: Invalid operation modernize-sources असे उत्तर देतो. त्या release मध्ये वरील field mapping वापरून manually रूपांतर करा.

आज रूपांतर करणे optional आहे, कारण apt अजूनही दोन्ही formats वाचतो. मात्र server पुढेही वापरण्याची योजना असल्यास हे करणे उपयुक्त आहे. आता sources लिहिणारे प्रत्येक tool deb822 वापरते. त्यामुळे फक्त .sources files असलेल्या system मध्ये या प्रकारची duplicate entry पुन्हा तयार होऊ शकत नाही.

सर्व्हरवरील तृतीय-पक्ष स्रोत सुव्यवस्थित ठेवा

तृतीय-पक्ष repositories हा सर्व्हरचा सर्वाधिक वेगाने जुना होणारा भाग आहे. तुमच्या Ubuntu release साठी पुढेही packages प्रकाशित ठेवण्याचे प्रत्येक repository हे दुसऱ्या कोणीतरी दिलेले आश्वासन असते. Release upgrade करताना त्याच दिवशी या सर्व आश्वासनांची पडताळणी होते.

• Distribution package पुरेसे काम करत नसेल, तेव्हाच तृतीय-पक्ष repository जोडा. साध्या Ubuntu 24.04 वरील LAMP stack साठी याची गरज नाही. त्यात वापरली जाणारी सर्व packages Ubuntu archive मध्ये उपलब्ध असतात आणि release च्या support कालावधीत security updates मिळतात.
• Keys /etc/apt/keyrings/ मध्ये ठेवा. प्रत्येक vendor साठी एक file वापरा आणि तिचा mode 644 ठेवा. Download करण्याचे काम unprivileged _apt user करतो आणि त्याला key वाचावी लागते. त्यामुळे केवळ root ला वाचता येणाऱ्या key file मुळे त्या repository मधून प्रत्येक fetch वेळी permission error येतो.
• प्रत्येक stanza मध्ये Signed-By ला त्या अचूक file कडे निर्देशित करा. /etc/apt/trusted.gpg किंवा /etc/apt/trusted.gpg.d/ मध्ये ठेवलेली key या मशीनवरील प्रत्येक repository साठी trusted असते. त्यामुळे अनेक वर्षांपूर्वी जोडलेली vendor key कुठूनही आलेली packages validate करू शकते.
• Release upgrade करण्यापूर्वी sources वाचा आणि तुम्ही ज्या suite कडे स्थलांतर करणार आहात त्यासाठी प्रत्येक vendor आधीच packages प्रकाशित करतो का ते तपासा.

जुन्या global keyring मधील key प्रत्येक update वेळी स्वतःची उपस्थिती दर्शवते:

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.

ती एकच key स्वतःच्या file मध्ये export करा आणि stanza ला त्या file कडे निर्देशित करा:

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

Repository च्या stanza मध्ये Signed-By: /etc/apt/keyrings/docker.gpg जोडा आणि sudo apt update चालवा. कोणतेही repository जुन्या keyring वर अवलंबून राहणार नाही तेव्हा warning थांबेल. त्यानंतर sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 वापरून ती entry काढू शकता.

आणखी एक सवय सर्वाधिक त्रास वाचवते. Upgrade साठी do-release-upgrade तृतीय-पक्ष sources disable करते आणि upgrade नंतरही ती बंद ठेवते. त्यांना पुन्हा हाताने, एकावेळी एक, सुरू करणे म्हणजे duplicate declarations तयार होण्याची नेमकी जागा असते. सुरुवात करण्यापूर्वी Ubuntu 24.04 ते 26.04 upgrade guide वाचा आणि अजून आवश्यक असलेल्या repositories ची नोंद करा. नुकत्याच तयार केलेल्या मशीनवर sources योग्य प्रकारे सेट करण्यासाठी सर्वात योग्य वेळ नवीन VPS वरील पहिल्या दहा मिनिटांत असतो. त्या वेळी मशीनवर केवळ Ubuntu ने release केलेल्या entries असतात.

FAQ

apt म्हणते की एखादा target अनेक वेळा configure केला आहे. असे का?

कारण /etc/apt/sources.list.d/ अंतर्गत असलेल्या दोन फाइल्समध्ये समान repository, suite आणि component घोषित केलेले आहेत. संदेशात line numbers सह दोन्ही फाइल्सची नावे दिली जातात, उदाहरणार्थ docker.list:1 आणि docker.sources:1. apt त्या दोन्ही नोंदी एकत्र करते आणि पुढे सुरू राहते, त्यामुळे update प्रत्यक्षात यशस्वी होते. तरीही duplicate नोंद काढून टाकणे योग्य आहे: दोन्ही फाइल्समध्ये वेगळ्या signing keys दिल्या असतील, तर apt E: Conflicting values set for option Signed-By सह थांबते आणि कोणतेही source वाचण्यास नकार देते. त्यामुळे apt install देखील अडते.

.list फाइल ठेवावी की .sources फाइल?

.sources फाइल ठेवा. Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये add-apt-repository deb822 फाइल लिहिते. यात प्रत्येक setting साठी स्वतंत्र नाव असलेले field असते; square brackets मधील positional text वापरला जात नाही. भविष्यात distributions हीच पद्धत वापरणार आहेत. .list फाइल हटवण्यापूर्वी, .sources फाइलमधील Signed-By path अस्तित्वात असलेल्या key कडे निर्देश करतो का ते ls -l /etc/apt/keyrings/ वापरून तपासा. जुनी फाइल /etc/apt/sources.list.d/ च्या बाहेर हलवा. ती त्याच directory मध्ये rename करू नका, कारण उरलेले .bak नाव प्रत्येक वेळी apt चालवल्यावर ignored-file सूचना दाखवते.

एखादे apt repository न हटवता ते बंद कसे करावे?

deb822 .sources फाइलमध्ये stanza मध्ये Enabled: no जोडा. एका ओळीच्या .list फाइलमध्ये ओळीच्या सुरुवातीला # ठेवा. दोन्हीपैकी कोणतीही पद्धत वापरल्यानंतर sudo apt update चालवा. त्यानंतर त्या repository साठीचा Err: block नाहीसा होईल. एखाद्या third-party repository मध्ये तुमच्या Ubuntu release साठी अद्याप packages उपलब्ध नसतील आणि त्याचा 404 मुळे apt update non-zero सह बंद होत असेल, तर हीच योग्य पद्धत आहे.

एका ओळीच्या sources.list format चा वापर बंद होणार आहे का?

तो deprecated आहे; हटवलेला नाही. apt अजूनही .list फाइल्स वाचते आणि दीर्घकाळ वाचत राहील. त्यामुळे तुमच्या server वर उद्या काही बिघडणार नाही. नवीन tooling deb822 लिहिते: Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये distribution repositories /etc/apt/sources.list.d/ubuntu.sources मध्ये असतात आणि add-apt-repository .sources फाइल्स लिहिते. apt 3.0 आणि त्यानंतरच्या आवृत्त्यांमध्ये sudo apt modernize-sources वापरून अजून अस्तित्वात असलेल्या फाइल्स रूपांतरित करता येतात.