duplicate apt sources ختم کرنے کا طریقہ

duplicate apt sources کی خرابی کا مطلب

Duplicate apt sources کا مطلب ہے کہ ایک repository دو مختلف files میں دو بار declare کی گئی ہے اور APT (advanced package tool) نے دونوں copies تلاش کر لی ہیں۔ Ubuntu 24.04 اور اس کے بعد کے versions میں یہ تقریباً ہمیشہ اس وجہ سے ہوتا ہے کہ کسی third-party install script نے پرانی one-line .list file لکھ دی، جبکہ اسی repository کے لیے deb822 .sources file پہلے سے disk پر موجود تھی۔ کچھ بھی corrupt نہیں ہوا اور کسی package کو خطرہ نہیں ہے۔ دونوں declarations میں سے ایک delete کر دیں، تو یہ message ختم ہو جائے گا۔

لوگ عموماً search box میں یہ line paste کرتے ہیں:

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 ہے جسے apt یہ معلوم کرنے کے لیے download کرتا ہے کہ repository کون سے packages پیش کرتی ہے، جبکہ stable/binary-amd64/Packages اس component (stable) اور architecture (amd64) کا نام ہے جس کا احاطہ وہ index کرتا ہے۔ اس لیے apt آپ کو بتا رہا ہے کہ stable component کا amd64 index docker.list میں line 1 پر configured ہے، اور دوبارہ docker.sources میں line 1 پر بھی موجود ہے۔

apt 3.0 اور اس کے بعد کے versions میں، یعنی Ubuntu 25.04 onward اور Debian 13 میں، یہی message W: کے بجائے Warning: سے شروع ہوتا ہے۔ Prefix کے بعد کا متن وہی رہتا ہے۔

یہ warning نسبتاً معمولی صورت ہے۔ apt دونوں declarations کو merge کر دیتا ہے اور update پھر بھی چلتا ہے، کیونکہ دونوں میں ایک ہی archive اور ایک ہی 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 انکار کرتا ہے، کیونکہ دونوں declarations ایک archive کے لیے مختلف signing keys بتاتی ہیں۔ apt دو یکساں declarations کو merge کر لیتا ہے، لیکن دو Signed-By values میں سے انتخاب نہیں کرتا، کیونکہ غلط value منتخب کرنے کا مطلب package signatures کو ایسی key کے خلاف verify کرنا ہے جس سے archive کے مالک نے کبھی sign نہیں کیا۔ اس لیے apt کوئی source نہیں پڑھتا۔ apt update اور apt install دونوں انہی دو lines کے ساتھ fail ہوتے رہتے ہیں، جب تک آپ files کو دستی طور پر edit نہ کریں۔

یہ duplicate وہاں کیسے پہنچتا ہے

دونوں formats الگ extensions والی الگ files میں موجود ہوتے ہیں، اس لیے disk پر کوئی چیز دونوں کے موجود ہونے کو نہیں روکتی۔ apt اس overlap کو اس وقت محسوس کرتا ہے جب یہ ہر source file کو ان index targets کی فہرست میں expand کرتا ہے جنہیں یہ fetch کرنے کا منصوبہ بناتا ہے۔ اس وقت تک docker.list اور docker.sources دو غیر متعلق files ہوتی ہیں۔

یہ چار عام واقعات اس جوڑے کو پیدا کرتے ہیں:

• کسی vendor کی install script، یا کسی پرانی post سے copy کیا گیا command، /etc/apt/sources.list.d/vendor.list کو tee line کے ساتھ لکھ دیتا ہے۔
• بعد میں vendor کا اپنا package /etc/apt/sources.list.d/vendor.sources فراہم کرتا ہے اور اسے آپ کے لیے install کر دیتا ہے۔
• Ubuntu 24.04 اور اس کے بعد کے versions میں add-apt-repository deb822 .sources files لکھتا ہے، اس لیے آپ کا پہلے دستی طور پر .list کے طور پر شامل کیا ہوا PPA (personal package archive) .sources کے طور پر دوبارہ آ جاتا ہے۔
• release upgrade نے distribution کے اپنے sources کو deb822 میں تبدیل کر دیا، لیکن آپ کی دستی طور پر لکھی ہوئی .list file کو وہیں چھوڑ دیا۔

ہر راستہ اپنی جگہ معقول ہے۔ duplicate اس وقت بنتا ہے جب ان میں سے دو واقعات ایک ہی box پر پیش آ جائیں، اکثر کئی ماہ کے وقفے سے۔

دونوں فارمیٹس، ساتھ ساتھ

پرانے فارمیٹ میں ہر repository کے لیے ایک لائن ہوتی ہے، اور اس کے تمام حصے اپنی مخصوص پوزیشن پر ہوتے ہیں۔

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

ترتیب مقرر ہوتی ہے: type (binary packages کے لیے deb، source packages کے لیے deb-src)، پھر square brackets میں options، اس کے بعد archive کا URI (uniform resource identifier)، پھر suite، اور آخر میں ایک یا زیادہ components۔ چونکہ معنی پوزیشن سے متعین ہوتے ہیں، اس لیے غلط جگہ پر موجود space سے apt کی parsing تبدیل ہو جاتی ہے۔

deb822 اسی معلومات کو نامزد fields کے stanza کے طور پر لکھتا ہے۔ اس کا نام RFC 822 سے لیا گیا ہے، جو mail header کا وہ انداز ہے جسے Debian پہلے ہی package control files کے لیے استعمال کرتا ہے۔

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

وہی repository، وہی key، کچھ بھی اضافی نہیں۔ mapping براہ راست ہے: deb، Types بن جاتا ہے؛ archive address، URIs بن جاتا ہے؛ suite، Suites بن جاتا ہے؛ components، Components بن جاتے ہیں؛ اور ہر bracket option اپنا الگ field بن جاتا ہے، اس لیے signed-by=، Signed-By: بن جاتا ہے اور arch=، Architectures: بن جاتا ہے۔

ہر field name جمع کی صورت میں ہوتا ہے، کیونکہ ہر field space سے جدا کی گئی فہرست قبول کرتا ہے۔ ایک stanza میں Suites: noble noble-updates noble-backports، تین الگ deb lines کی جگہ لے لیتا ہے۔ خالی لائن stanza ختم کرتی ہے، اس لیے ایک ہی .sources file میں متعدد repositories رکھی جا سکتی ہیں۔ deb822 ایسی settings بھی محفوظ کرتا ہے جنہیں one line format مناسب طور پر handle نہیں کرتا: repository بند کرنے کے لیے Enabled: no، Trusted، Check-Valid-Until، اور inline key جسے براہ راست Signed-By میں paste کیا جاتا ہے؛ اس میں ہر line ایک space سے indent ہوتی ہے اور خالی lines ایک dot کے طور پر لکھی جاتی ہیں۔

ہر فائل کہاں موجود ہے

• /etc/apt/sources.list: اصل واحد فائل۔ Ubuntu 24.04 اور اس کے بعد کے ورژنز میں یہ عموماً خالی ہوتی ہے یا نئی جگہ کی طرف اشارہ کرنے والا صرف ایک comment رکھتی ہے۔
• /etc/apt/sources.list.d/*.list: ہر repository کے لیے عموماً ایک فائل پر مشتمل، ایک سطر والی entries۔
• /etc/apt/sources.list.d/*.sources: deb822 stanzas۔ Ubuntu 24.04 اور اس کے بعد کے ورژنز میں distribution کی اپنی repositories یہاں، ubuntu.sources میں، موجود ہوتی ہیں۔
• /etc/apt/keyrings/: آپ کی شامل کردہ keys یہاں ہونی چاہییں۔ /usr/share/keyrings/ میں package سے حاصل ہونے والی keys رکھی جاتی ہیں۔

apt صرف ان فائلوں کو پڑھتا ہے جن کے نام .list یا .sources پر ختم ہوتے ہیں، اور filename میں 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 والی دو فائلیں عام طور پر یہ جوڑا ہوتی ہیں، لیکن ناموں پر بھروسا نہ کریں۔ مواد پڑھیں، کیونکہ نقل کسی بھی نام والی فائل میں چھپی ہو سکتی ہے:

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

یہ جوڑا وہ دو entries ہیں جن کا host اور suite ایک ہی ہے۔ دونوں 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 فائل برقرار رکھیں، پرانی فائل ہٹا دیں

.sources فائل برقرار رکھیں۔ یہی وہ فارمیٹ ہے جس میں apt tooling اب فائل لکھتی ہے، اور Debian اور Ubuntu دونوں اسی سمت بڑھ رہے ہیں۔ کچھ بھی حذف کرنے سے پہلے یہ دیکھیں کہ disk پر دو اہم 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 کی طرف اشارہ کر رہی ہے جسے ہٹا دیا گیا ہے۔ اگر معلوم ہو کہ جس فائل کو آپ برقرار رکھنا چاہتے ہیں، اس میں missing key کا نام درج ہے، تو پہلے اس میں کام کرنے والا path copy کریں، پھر دوسری فائل حذف کریں۔

پرانی فائل کو فوراً حذف کرنے کے بجائے اسے 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

فائل کو کسی دوسری جگہ منتقل کرنے سے یہ اطلاع آپ کی screen پر ظاہر نہیں ہوتی اور 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 فائل فرض کرتی ہے، تو آپ وہ فائل برقرار رکھ کر اس کے بجائے .sources فائل حذف کر سکتے ہیں۔ دونوں صورتوں میں ایک ہی اصول لاگو ہوتا ہے: کسی archive اور suite کو declare کرنے کے لیے صرف ایک فائل موجود ہونی چاہیے۔

ایک خراب third-party source apt update کو کیوں روک دیتا ہے

قریب سے متعلقہ failure مختلف دکھائی دیتی ہے، لیکن اس کی بنیادی وجہ وہی ہے: ایسا third-party source جسے apt استعمال نہیں کر سکتا۔ پہلی صورت میں 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 فیلڈ موجود نہیں، یا یہ ایسی file کی طرف اشارہ کرتی ہے جو قابلِ استعمال key نہیں ہے۔ اس لیے apt archive کی InRelease file پر موجود signature کی تصدیق نہیں کر سکتا۔ پھر یہ پورے repository کو مسترد کر دیتا ہے، کیونکہ ایسے package lists پر اعتماد نہیں کیا جا سکتا جن کی جانچ نہ ہو سکے۔ خود 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 دوبارہ حاصل کریں، 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 کے لیے کچھ شائع نہیں کیا، اس لیے server پر path موجود نہیں اور request کا جواب 404 آتا ہے۔ آپ کے دیگر repositories پھر بھی update ہو جاتے ہیں، اور پہلے سے نصب packages متاثر نہیں ہوتے۔ تاہم run non-zero status کے ساتھ ختم ہوتا ہے۔ اس لیے apt update کا exit status چیک کرنے والی کوئی بھی script ہر بار failure رپورٹ کرتی ہے۔ اسی وجہ سے غیر نگرانی شدہ security upgrades configured والے server پر ایک غیر فعال source کو صاف کرنا ضروری ہے: روزانہ آنے والے پیغامات میں حقیقی failure چھپی رہتی ہے۔

ایک source کو باقی sources کو متاثر کیے بغیر غیر فعال کریں

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

apt manual ہر لائن پر comment لگانے کے بجائے اس طریقے کی تجویز کرتا ہے، اور اسے واپس کرنا بھی آسان ہے۔ ایک لائن والی فائل کے لیے لائن کے آغاز میں # رکھیں۔ دونوں formats میں فائل کو /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 اور اس کے بعد کے versions میں یہ ubuntu.sources حذف کر دیتا ہے۔ اس میں distribution کی اپنی repositories موجود ہوتی ہیں۔ نتیجتاً apt کے پاس کوئی package lists باقی نہیں رہتیں، اور ایسے software کے لیے E: Unable to locate package curl رپورٹ ہوتا ہے جو واضح طور پر موجود ہے۔ اگر آپ پہلے ہی یہ command چلا چکے ہیں تو فائل دوبارہ لکھیں:

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

یہ /etc/apt/sources.list.d/ کے تحت موجود one-line فائلوں کو deb822 .sources فائلوں میں دوبارہ لکھتا ہے۔ اس کے output کو پڑھیں، پھر خود directory کی فہرست دیکھیں اور نتیجے پر اعتماد کرنے سے پہلے apt update چلائیں۔ Ubuntu 24.04 میں apt کا پرانا ورژن شامل ہے جس میں ایسا subcommand موجود نہیں؛ وہاں command E: Invalid operation modernize-sources جواب دیتی ہے۔ اس release میں اوپر دی گئی field mapping کے مطابق دستی طور پر تبدیل کریں۔

آج تبدیل کرنا اختیاری ہے، کیونکہ apt اب بھی دونوں formats پڑھتا ہے۔ تاہم، جس server کو آپ برقرار رکھنے کا ارادہ رکھتے ہیں، اس پر یہ کام کرنا مفید ہے، کیونکہ اب sources لکھنے والا ہر tool deb822 استعمال کرتا ہے، اور صرف .sources فائلوں والا box اس قسم کی duplicate فائل شامل نہیں کر سکتا۔

سرور پر third-party sources کو منظم رکھیں

Third-party repositories سرور کا وہ حصہ ہیں جو سب سے تیزی سے پرانا ہوتا ہے۔ ہر repository اس کے maintainers کی طرف سے یہ وعدہ ہوتی ہے کہ وہ آپ کی Ubuntu release کے لیے packages جاری کرتے رہیں گے، اور release upgrade اسی دن ان تمام وعدوں کو جانچتی ہے۔

• Third-party repository صرف اس وقت شامل کریں جب distribution package آپ کی ضرورت پوری نہ کرے۔ سادہ Ubuntu 24.04 پر LAMP stack کے لیے کسی کی ضرورت نہیں: Ubuntu archive میں اس کے استعمال ہونے والے تمام packages موجود ہیں، اور release کی مدت تک security updates بھی ملتی رہتی ہیں۔
• Keys کو /etc/apt/keyrings/ میں رکھیں، ہر vendor کے لیے ایک file، mode 644 کے ساتھ۔ غیر privileged _apt user downloading کرتا ہے اور اسے key پڑھنی ہوتی ہے، اس لیے صرف root کے لیے readable key file سے اس repository سے ہر fetch پر permission error آتا ہے۔
• ہر stanza میں Signed-By کو اسی exact file کی طرف point کریں۔ /etc/apt/trusted.gpg یا /etc/apt/trusted.gpg.d/ میں موجود key پورے server کی ہر repository کے لیے trusted ہوتی ہے۔ اس کا مطلب ہے کہ کئی سال پہلے شامل کی گئی vendor key کہیں سے بھی آنے والے packages کو validate کر سکتی ہے۔
• Release upgrade سے پہلے اپنی sources پڑھیں اور تصدیق کریں کہ ہر vendor اس suite کے لیے پہلے ہی 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.

اس single key کو اپنی الگ file میں export کریں، پھر stanza کو اسی file کی طرف point کریں:

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 پر depend نہ کرے تو warning ختم ہو جاتی ہے، اور اس کے بعد آپ sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 کے ذریعے entry ہٹا سکتے ہیں۔

ایک اور عادت سب سے زیادہ مشکلات سے بچاتی ہے۔ do-release-upgrade upgrade کے لیے third-party sources کو disable کرتی ہے اور upgrade کے بعد بھی انہیں بند رکھتی ہے۔ اس کے بعد انہیں ایک ایک کر کے manually دوبارہ enable کرنا عین وہ مرحلہ ہے جہاں duplicate declarations بن جاتی ہیں۔ شروع کرنے سے پہلے Ubuntu 24.04 سے 26.04 upgrade guide پڑھیں، اور لکھ لیں کہ آپ کو اب بھی کون سی repositories درکار ہیں۔ ابھی بنائی گئی machine پر sources درست کرنے کا سب سے آسان وقت نئے VPS کے پہلے دس منٹ کے دوران ہوتا ہے، جب server پر صرف وہ entries موجود ہوتی ہیں جو Ubuntu نے فراہم کی ہیں۔

FAQ

apt یہ کیوں کہتا ہے کہ کوئی target متعدد بار configured ہے؟

کیونکہ /etc/apt/sources.list.d/ کے تحت موجود دو فائلیں ایک ہی repository، suite اور component declare کرتی ہیں۔ پیغام دونوں فائلوں کے نام line numbers کے ساتھ دکھاتا ہے، مثلاً docker.list:1 اور docker.sources:1۔ apt انہیں merge کرکے کام جاری رکھتا ہے، اس لیے update خود کام کرتی ہے۔ پھر بھی duplicate کو ختم کرنا بہتر ہے: جیسے ہی دونوں فائلیں مختلف signing keys بیان کریں گی، apt E: Conflicting values set for option Signed-By کے ساتھ رک جائے گا اور کوئی بھی source پڑھنے سے انکار کر دے گا، جس سے apt install بھی رک جائے گا۔

کیا مجھے .list فائل رکھنی چاہیے یا .sources فائل؟

.sources فائل رکھیں۔ deb822 وہ format ہے جسے add-apt-repository Ubuntu 24.04 اور اس کے بعد کے ورژنز پر لکھتا ہے۔ اس میں ہر setting کے لیے square brackets کے اندر positional text کے بجائے ایک نامزد field ہوتا ہے، اور distributions اسی format کی طرف بڑھ رہی ہیں۔ .list فائل حذف کرنے سے پہلے .sources فائل میں موجود Signed-By path کی تصدیق کریں کہ وہ ایسی key کی طرف اشارہ کرتا ہے جو موجود ہے، اس کے لیے ls -l /etc/apt/keyrings/ استعمال کریں۔ پرانی فائل کو /etc/apt/sources.list.d/ سے باہر منتقل کریں، directory کے اندر اس کا نام تبدیل نہ کریں، کیونکہ بچا ہوا .bak نام ہر run پر apt سے ignored-file notice جاری کرواتا ہے۔

کسی apt repository کو حذف کیے بغیر اسے کیسے بند کروں؟

deb822 .sources فائل میں stanza کے اندر Enabled: no شامل کریں۔ ایک لائن والی .list فائل میں line کے شروع میں # رکھیں۔ دونوں صورتوں میں اس کے بعد sudo apt update چلائیں، اور اس repository کا Err: block ختم ہو جائے گا۔ یہ اس وقت درست طریقہ ہے جب کسی third-party repository میں ابھی آپ کی Ubuntu release کے لیے packages موجود نہ ہوں اور اس کا 404 apt update کو non-zero exit کے ساتھ بند کر رہا ہو۔

کیا one line 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 ان فائلوں کو convert کر دیتا ہے جو آپ کے پاس اب بھی موجود ہیں۔