duplicate apt sources اور deb822 files ٹھیک کریں

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 میں سے ایک حذف کر دیں، پیغام ختم ہو جائے گا۔

یہ وہ line ہے جسے لوگ search box میں 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، اور ہر file میں 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 پر بھی configured ہے۔

apt 3.0 اور اس کے بعد کے versions میں، یعنی Ubuntu 25.04 onward اور Debian 13 میں، یہی پیغام 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 بتاتی ہیں۔ apt دو یکساں declarations کو merge کر دے گا، لیکن دو Signed-By values میں سے کسی ایک کا انتخاب نہیں کرے گا، کیونکہ غلط value منتخب کرنے کا مطلب package signatures کو ایسی key کے خلاف verify کرنا ہے جس سے archive owner نے کبھی 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 ہوتی ہیں۔

چار عام events یہ جوڑا بناتے ہیں:

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

ہر path اپنی جگہ درست ہے۔ duplicate اس وقت بنتا ہے جب ان میں سے دو events ایک ہی 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 separated list قبول کرتی ہے۔ ایک 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، اور Signed-By میں براہ راست paste کی گئی inline key، جس کی ہر سطر کے آغاز میں ایک space indent ہو اور خالی سطریں single dot کے طور پر لکھی جائیں۔

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

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

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 والی دو فائلیں عموماً مطلوبہ جوڑی ہوتی ہیں، لیکن ناموں پر اعتماد نہ کریں۔ مواد پڑھیں، کیونکہ 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

جوڑی وہ دو entries ہیں جن میں host اور suite ایک جیسے ہیں۔ دونوں 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 دونوں اسی سمت بڑھ رہے ہیں۔ کچھ بھی حذف کرنے سے پہلے دیکھیں کہ 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 درج ہے، تو پہلے اس میں working 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

فائل کو کسی دوسری جگہ منتقل کرنے سے یہ اطلاع ظاہر نہیں ہوتی اور 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.

اب تصدیق کریں کہ edit کے بعد 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 کو کیوں روک دیتا ہے

قریب کی خرابی مختلف دکھائی دیتی ہے، لیکن اس کی بنیادی وجہ وہی ہے: ایسا 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 کا exit status non-zero ہوتا ہے۔ اس لیے جو script apt update کے exit status کی جانچ کرتی ہے، وہ ہر بار failure report کرتی ہے۔ اسی وجہ سے unattended security upgrades configured والے system پر ایک ناکام source کو صاف کرنا ضروری ہے: روزانہ کا غیر ضروری شور حقیقی failure کو چھپا دیتا ہے۔ Vendor install scripts میں یہ دونوں صورتیں پیش آتی ہیں۔ اسی لیے Ubuntu پر Tailscale install errors میں عموماً مسئلہ ایسے keyring کا ہوتا ہے جسے script نے لکھا ہی نہیں، یا ایسے release codename کا جسے archive support نہیں کرتا۔

ایک 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، stanza کی ہر line کے شروع میں comment شامل کرنے کے بجائے اس طریقے کی تجویز کرتا ہے۔ اسے واپس سابقہ حالت میں لانا بھی آسان ہے۔ ایک line والی فائل کے لیے line کے شروع میں # لگائیں۔ دونوں formats میں فائل کو /etc/apt/sources.list.d/ سے باہر منتقل کرنا بھی کارآمد ہے۔ جب repository مستقل طور پر ختم ہو چکی ہو تو یہی طریقہ اختیار کریں۔

دوبارہ sudo apt update چلائیں۔ اس repository کے لیے Err: block غائب ہو جائے گا، اور exit status دوبارہ 0 ہو جائے گا۔ اگلی line پر echo $? سے اسے چیک کیا جا سکتا ہے۔

کبھی بھی sudo rm /etc/apt/sources.list.d/* سے broken source ٹھیک نہ کریں۔ Ubuntu 24.04 اور اس کے بعد کے versions میں یہ ubuntu.sources کو delete کر دیتا ہے، جس میں 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

یہ /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 فائلوں والے server میں اس قسم کی duplicate شامل نہیں ہو سکتی۔

سرور پر فریقِ ثالث کے ذرائع منظم رکھیں

فریقِ ثالث کی repositories سرور کا وہ حصہ ہیں جو سب سے تیزی سے پرانا ہوتا ہے۔ ہر repository کسی دوسرے فریق کا یہ وعدہ ہوتی ہے کہ وہ آپ کی Ubuntu release کے لیے packages شائع کرتا رہے گا۔ Release upgrade اسی دن ان تمام وعدوں کو جانچتی ہے۔

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

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

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

FAQ

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

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

مجھے .list file رکھنی چاہیے یا .sources file؟

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

کسی apt repository کو remove کیے بغیر اسے کیسے بند کروں؟

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

کیا one line sources.list format ختم ہونے والا ہے؟

یہ deprecated ہے، ختم نہیں کیا گیا۔ apt اب بھی .list files پڑھتا ہے اور طویل عرصے تک پڑھتا رہے گا، اس لیے آپ کا server اگلے دن اچانک متاثر نہیں ہوگا۔ نئے tools deb822 لکھتے ہیں: Ubuntu 24.04 اور اس کے بعد کے versions میں distribution repositories /etc/apt/sources.list.d/ubuntu.sources میں رکھی جاتی ہیں، اور add-apt-repository، .sources files لکھتا ہے۔ apt 3.0 اور اس کے بعد کے versions میں sudo apt modernize-sources آپ کی موجودہ files کو convert کرتا ہے۔