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

duplicate apt sources त्रुटीचा अर्थ

Duplicate 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

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

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

डुप्लिकेट कसे तयार होते

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

ही जोडी साधारणपणे पुढील चार घटनांमुळे तयार होते:

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

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

प्रत्येक फाइल कुठे असते

• /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 असलेली फाइल notice देऊन वगळली जाते. खालील दुरुस्तीसाठी हा मुद्दा महत्त्वाचा आहे.

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

डिरेक्टरीची सूची पाहून सुरुवात करा:

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

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 ची सूचीही दाखवू शकत नाही. त्यामुळे apt-cache policy तुम्हाला अपेक्षित उत्तर देण्याऐवजी तीच error पुन्हा दाखवते.

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

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

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 तिच्यामध्ये कॉपी करा. त्यानंतर दुसरी फाइल हटवा.

जुनी फाइल थेट हटवण्याऐवजी ती 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

फाइल दुसरीकडे हलवल्यास हा संदेश दिसत नाही आणि backup देखील सुरक्षित राहतो. त्यानंतरची योग्य apt update स्थिती खालीलप्रमाणे दिसते. त्यात दोन फाइल्सची नोंद करणारी कोणतीही 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 मधील बदलानंतर ती व्यवस्थित उपलब्ध आहे याची खात्री करा:

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 गृहीत धरली असल्यास, ती फाइल ठेवून त्याऐवजी .sources फाइल हटवू शकता. दोन्ही परिस्थितींमध्ये एकच नियम लागू होतो: दिलेल्या archive आणि suite ची घोषणा करणारी नेमकी एकच फाइल असावी.

एक बिघडलेला third-party source apt update का अडवतो

लगतचे अपयश वेगळे दिसते, पण त्याचे मूळ कारण तेच आहे: apt वापरू शकत नसलेला third-party source. पहिली आवृत्ती 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 missing आहे किंवा ते 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 जतन झालेली असते. 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.

PPA ने त्या suite साठी काहीही publish केलेले नाही. त्यामुळे server वर तो path अस्तित्वात नसतो आणि request ला 404 मिळतो. तुमचे इतर repositories update होत राहतात आणि आधीपासून installed असलेल्या packages वर परिणाम होत नाही. मात्र run non-zero ने समाप्त होतो. त्यामुळे apt update चा exit status तपासणारी कोणतीही script प्रत्येक वेळी failure report करते. unattended security upgrades configured असलेल्या box वर एक dead source काढून टाकणे महत्त्वाचे आहे. दैनंदिन noise मध्येच खरे failure लपते.

उर्वरित स्रोतांवर परिणाम न करता एक स्रोत अक्षम करा

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 मधील प्रत्येक ओळ टिप्पणी म्हणून निष्क्रिय करण्यापेक्षा हा मार्ग वापरण्याची शिफारस apt manual मध्ये केली आहे. हा बदल पूर्ववत करणेही सोपे आहे. एका ओळीच्या फाइलसाठी ओळीच्या सुरुवातीला # लिहा. दोन्ही स्वरूपांसाठी फाइल /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 चालवा.

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

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

apt --version
sudo apt modernize-sources

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

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

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

तृतीय-पक्ष रिपॉझिटरी हा सर्व्हरचा सर्वात लवकर जुना होणारा भाग असतो. तुमच्या Ubuntu release साठी प्रकाशने जारी ठेवण्याचे वचन प्रत्येक रिपॉझिटरी दुसऱ्या कोणावर तरी अवलंबून ठेवते. Release upgrade दरम्यान त्यापैकी प्रत्येक वचनाची एकाच वेळी चाचणी होते.

• Distribution package पुरेसे काम करत नसेल तरच तृतीय-पक्ष रिपॉझिटरी जोडा. साध्या Ubuntu 24.04 वरील LAMP stack साठी त्यांची गरज नाही. Ubuntu archive मध्ये त्यासाठी लागणारी सर्व packages असतात आणि 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 चे validation करू शकते.
• Release upgrade करण्यापूर्वी तुमचे sources वाचा आणि ज्या suite कडे तुम्ही स्थलांतर करणार आहात त्यासाठी प्रत्येक vendor आधीपासून प्रकाशने जारी करतो का ते तपासा.

जुन्या 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 करते आणि नंतरही ते बंद ठेवते. त्यांना एकावेळी एक करून हाताने पुन्हा सुरू करणे म्हणजे duplicate declarations निर्माण होण्याची नेमकी जागा असते. सुरुवात करण्यापूर्वी Ubuntu 24.04 ते 26.04 upgrade guide वाचा आणि अजून कोणत्या repositories आवश्यक आहेत ते लिहून ठेवा. नुकतेच तयार केलेल्या मशीनवर sources योग्य करण्यासाठी सर्वात स्वस्त वेळ म्हणजे नवीन VPS वरील पहिली दहा मिनिटे. त्या वेळी सर्व्हरवर Ubuntu ने उपलब्ध करून दिलेल्या entries शिवाय इतर काहीही नसते.

FAQ

apt एखादे लक्ष्य अनेक वेळा कॉन्फिगर केलेले असल्याचे का सांगते?

कारण /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 साठी square brackets मधील positional text ऐवजी या फाइलमध्ये एक named field असते. Distributions याच स्वरूपाकडे जात आहेत. .list फाइल हटवण्यापूर्वी .sources फाइलमधील Signed-By path अस्तित्वात असलेल्या key कडे निर्देश करतो का हे ls -l /etc/apt/keyrings/ ने तपासा. जुनी फाइल /etc/apt/sources.list.d/ मधून बाहेर हलवा; ती त्याच directory मध्ये rename करू नका. उरलेले .bak नाव असल्यास apt प्रत्येक run वेळी ignored-file notice दाखवते.

एखादे 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 exit करत असेल, तेव्हा ही योग्य पद्धत आहे.

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

ते deprecated आहे, पण removed नाही. 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 तुमच्याकडे अजून असलेल्या फाइल्स रूपांतरित करते.