Perbedaan dalam manajemen paket antara Debian dan Arch


9

Diskusi dari pos ini membuat saya ingin tahu perbedaan antara manajemen paket Debian dan Arch. Juga, orang-orang cenderung mengatakan bahwa Arch sangat ringan, jadi saya ingin tahu apa hubungannya dengan manajemen paket. Apakah mungkin karena Debian memperlakukan Rekomendasi sebagai dependensi keras secara default?

Bisakah Anda juga menyebutkan fleksibilitas / kekuatan antara dua manajer paket: mana dari keduanya yang memungkinkan Anda melakukan lebih banyak.

Saya menyadari bahwa beberapa fitur yang tersedia pada sistem manajemen paket Debian tidak akan relevan pada sistem Arch, karena Arch memiliki satu Suite dan Debian memiliki banyak (misalnya, penyematan APT dan penanganan ketergantungan tingkat lanjut muncul dalam pikiran), jadi silakan bandingkan fitur yang berlaku untuk kedua sistem (yaitu menganggap bahwa untuk Debian, saya hanya menggunakan tidak stabil ).


CATATAN : Oleh manajemen paket Debian saya mengacu pada APT, aptitude, dan dpkg. Saya tidak terbiasa dengan alat Arch, jadi saya tidak tahu apakah ada selain Pacman.
tshepang

Jawaban:


7

Saya hanya menggunakan lengkungan secara teratur sejak beberapa minggu dan saya bukan ahli dalam hal ini sehingga jawaban ini sama sekali tidak lengkap, hanya beberapa poin yang saya perhatikan tentang "fleksibilitas / kekuatan":

  • Ini hanya kesan tetapi pacman tampaknya lebih modern dan sederhana dalam desain / arsitekturnya. Setidaknya ada jauh lebih sedikit alat untuk menangani. Walaupun saya tidak tahu kode sumber yang tepat, saya kebetulan melihat kode libalpm (pustaka yang mendasari pacman) untuk membuat tambalan yang sangat sederhana, dan tampaknya bersih dan mudah dimengerti.

  • Ini juga sangat cepat (karena optimasi dan juga mungkin dengan memperhatikan beberapa hal (lihat di bawah)). Rilis terakhir (pacman 3.5, berusia beberapa hari) mencoba meningkatkan kinerja dengan mengurangi jumlah file database yang terlibat.

  • Sementara arch berorientasi pada penggunaan paket biner, ia juga memiliki keuntungan ketika membangun paket dari sumber, dengan sistem build yang mirip dengan port BSD (ABS).

  • Sangat mudah dan cepat untuk membuat paket, hanya beberapa baris dalam file PKGBUILD dan selesai, tidak perlu berurusan dengan kontrol / aturan / hak cipta / changelog / apa pun seperti dengan paket Debian. Dan dalam beberapa klik di web ui paket Anda dibagikan kepada semua orang di AUR (Arch User Repository).

Hal-hal yang saya dapatkan di Debian dan bukan di lengkungan:

  • Pemicu / pengait (yang membuat apt memperbarui cache ikon, mandb atau apa pun hanya dengan melihat di mana paket menginstal file, tanpa perlu paket untuk melakukan apa pun) (sepertinya ada rencana untuk mengimplementasikan ini).

  • debconf (bukan masalah besar dan omong-omong dengan memaksa saya untuk melakukan hal-hal secara manual itu memaksa saya untuk mengetahui apa yang sebenarnya dilakukan) dan penanganan yang tepat dari file konfigurasi baru (saya setidaknya ingin pacman mengetahui kapan file konfigurasi dalam paket baru versi berbeda dari yang diinstal karena diubah dalam versi baru atau karena saya memodifikasinya secara lokal).

  • penandatanganan paket (sepertinya sedang dikerjakan ).

Untuk lengkungan yang ringan, satu-satunya alasan sebenarnya adalah bahwa ia datang dengan beberapa paket diinstal secara default dan Anda didorong untuk menambahkan apa yang Anda butuhkan, jadi mungkin tidak menginstal dependensi opsional secara default adalah menghasut pengguna untuk menginstal menghindari bloat.


Saya tidak dapat menguraikan ini: tetapi saya bisa melakukannya tanpanya dan omong-omong saya tahu apa yang lebih baik saya lakukan . Ada juga salah ketik pada kalimat terakhir.
tshepang

Bahasa apa yang digunakan manajer paket pacman? Apakah ia memiliki fungsi manajemen paket tingkat rendah dan tingkat tinggi yang mirip dengan dpkg / apt, dan jika demikian, apa sebutannya?
Faheem Mitha

@Tepanget: maaf, penutur bahasa Inggris non-pribumi di sini. Maksud saya "ini bukan masalah besar bagi saya untuk tidak memiliki fungsi ini (debconf) dan dengan memaksa saya untuk melakukan hal-hal secara manual itu memaksa saya untuk mengetahui apa yang sebenarnya dilakukan".
gentledevil

@Faheem Mitha: Pacman ditulis dalam C, dan merupakan frontend ke libalpm, yang menangani manajemen paket "level tinggi" dan "level rendah".
gentledevil

@zanko: Saya juga bukan penutur asli. Yang saya ingin Anda lakukan adalah membuat kalimat lebih jelas, dan bukan dalam komentar, tetapi pada posting itu sendiri. BTW, kesalahan ketik yang saya sebutkan adalah opsional . Saya dapat mengedit posting sendiri, tetapi saya pikir Anda sebaiknya memperbaikinya bersama dengan bagian klarifikasi.
tshepang

6

Saya memulai perjalanan Linux saya dengan Ubuntu jernih, dan saat ini menggunakan Arch. Saya telah menulis beberapa paket Arch, dan saya akan mengatakan ini jauh lebih mudah daripada menulis paket Debian. Tapi, saya ingin menunjukkan ke @gentledevil bahwa Arch memang memiliki sistem kait untuk paket, yang dikenal sebagai install file.

Pada dasarnya, namanya ${pkgname}.install, dan berisi beberapa fungsi untuk pra / pasca pemasangan / penghapusan / peningkatan; cukup tempatkan pembaruan font-cache Anda di situ dan seterusnya dan berfungsi hampir sama dengan kait Debian.

Juga, saya perhatikan Anda menyebutkan 'menyematkan' aplikasi menggunakan alat manajemen paket debian; Pacman Arch memiliki built-in itu juga, /etc/pacman.confmenerima sejumlah pengaturan, termasuk IgnorePkg =, yang akan mencegah pemutakhiran ke paket apa pun yang terdaftar setelah yang sama (dibatasi ruang)


1
Selain itu, walaupun ini bukan paket repo, Anda dapat menggunakan powerpillpembungkus untuk pacman untuk memiliki unduhan paralel dari beberapa paket, jadi alih-alih pacman -S libfoo libbar libbazmengunduh setiap paket satu demi satu, ia malah mengunduh ketiganya secara bersamaan, sangat meningkatkan kecepatan pemutakhiran untuk koneksi yang lebih baik.
hanetzer

-1

Sebelum saya melangkah terlalu jauh, pelajari Timeline Pictorial Linux

Untuk memahami perbedaan dalam Pengelola Paket, Anda harus memahami filosofi OS yang digambarkan di atas


Tiga Orang Tua Utama

  1. Redhat, Sekarang Fedora - Package Palungan - RPM, kependekan dari Redhat Package Manager, baris perintah rpm
  2. Slackware - Package Manager - tgz, file zip biasa. Walaupun ini hanya file terkompresi, slackware dibangun oleh hulu dan ditempatkan di repositori, kadang-kadang disebut sebagai port
  3. Debian - DEB, kependekan dari Debian, itu adalah alat baris perintah Aptitude or Apt

Orang tua ini adalah ibu dan ayah bagi sebagian besar distribusi yang kita kenal sekarang. Gagasan / konsep Sistem Manajemen Paket diturunkan atau dibagikan dalam beberapa bentuk atau cara. Apapun, semua orang tua ini adalah distributor biner, yang berarti bahwa suatu program dikemas dan diputuskan oleh pihak ke-3, kemudian disimpan dalam repositori, dan dikonsumsi atau diinstal oleh basis pengguna.

3 Orangtua Kecil

  1. Linux Dari Awal - Berbasis Sumber, tidak ada manajer paket.
  2. Gentoo - Berasal dari Linux dari Awal . Distribusi ini pada dasarnya adalah Linux dari Scratch plus manajer paket, yang disebut Portage / emerge
  3. SourceMage - Package Manager Sihir

Orang tua ini kecil karena basis perdagangan mereka kecepatan dan kemudahan instalasi dengan kekuatan dan kemudahan konfigurasi. Setiap paket diunduh dan dikompilasi dari awal, menggunakan variabel dan file konfigurasi.

Jembatan

Arch dibuat sebagai jembatan antara distribusi biner, seperti salah satu dari 3 Orang Tua Utama, dan distribusi berbasis sumber seperti salah satu dari 3 Orang Tua Kecil. Dengan demikian, ia menerima status sebagai orang tua di timeline, karena tidak ada orang tua lain yang menyediakan fungsi ini. Pacman memiliki fleksibilitas untuk memungkinkan pengguna menginstal paket biner dari repositori resmi, atau paket yang dibuat khusus menggunakan Arch Build System. Konsep ini memberikan keseimbangan antara kekuatan yang diberikan orang tua minor dengan kemudahan pemasangan yang diberikan orang tua utama.


Menurut pendapat saya, bukan manajer paket yang menunjukkan kekuatan suatu sistem, karena semua manajer paket melakukan tugas yang sama, yaitu mengelola dan memelihara sistem yang sehat. Dengan demikian, sistem yang Anda gunakan harus ditentukan oleh faktor-faktor seperti:

  • Level Pengguna: Seseorang yang baru mengenal linux harus memulai dengan Induk Utama, sedangkan seseorang yang secara teknis cakap akan menemukan keseimbangan.
  • Apa yang ingin Anda lakukan dengan sistem Anda: Menjalankan server LAMP dengan pengguna yang terhubung sama sekali berbeda dengan menjalankan PC desktop untuk penelusuran web dan membaca e-mail.
  • Tingkat Kenyamanan: Tingkat pengguna tidak tahan, jika Anda mahir secara teknis, tetapi tidak ingin menghabiskan akhir pekan menyusun sistem, Anda akan memilih induk utama, terlepas dari apakah semua orang yang Anda kenal memilih sesuatu yang lain.

Ini lebih difokuskan pada geneaologi distribusi, daripada perbandingan alat manajemen paket pacman dan Debian ...
jasonwryan

@jasonwryan Itulah intinya, karena semua manajer paket menyelesaikan tugas yang sama, yaitu emerge packagenamesama dengan sudo apt-get install packagename.
eyoung100

Pada level itu, ya; tetapi itu sepenuhnya meleset dari inti pertanyaan, yaitu., apa yang membedakan pacman dari {apt, aptitude}.
jasonwryan

@jasonwryan saya menjawab itu di bagian The Bridge. Selain itu, tidak ada perbedaan. Satu-satunya perbedaan adalah semantik, yaitu satu perintah versus yang lain. Jika OP mencari perbedaan semantik, ada manual untuk itu.
eyoung100

-3

Ini sama sekali bukan jawaban yang lengkap atau lengkap - poster sebelum saya sudah memberikan beberapa poin yang sangat bagus, saya hanya ingin menambahkan 2 sen saya. Hal lain - saya tidak pernah terbiasa dengan apt / dpkg. Itu selalu tampak terlalu rumit bagi saya, saya benar-benar paling nyaman dengan yum / rpm.

pacman sangat mudah digunakan, yang pro dan kontra - Anda bisa belajar menggunakannya (mengesampingkan paket) dalam satu sore - sebagian besar menggunakan fitur manajemen paket yang intuitif dan lengkap, tapi - dan ini besar tapi - itu sangat tidak fleksibel.

Jika para desainer tidak memikirkan fitur sebelumnya, Anda kacau.

Beberapa contoh: tidak ada versi asli dalam pacman. Jika Anda ingin menurunkan versi versi paket - Anda harus mengunduh versi paket tertentu, dan menggunakan opsi -U (upgrade) untuk menginstal dari file. Ini sangat diarahkan untuk selalu menggunakan paket-paket canggih pada sistem Anda.

Tidak ada pembersihan cache internal nyata / pembangunan kembali lengkap. Jika (karena masalah jaringan) unduhan paket rusak, misalnya selama -Syu, pesan kesalahan, meskipun akurat, tidak akan banyak berguna - itu tidak akan menunjukkan paket yang rusak bahkan dengan verbositas "penuh" dan debug diaktifkan. , dan jumlah -Syyc tidak akan benar-benar membersihkan cache dan mengunduh ulang paket. Berita baiknya adalah -Sc akan memberi tahu Anda di mana paket yang diunduh jadi Anda bisa menghapus yang menyinggung (jika Anda bisa mencari tahu yang mana) atau semuanya dan restart -Syu.

integrasi pacman dengan dkms juga agak bermasalah - saat memasang kernel baru saya terus mengalami kesalahan dari dkms. Menggunakan dkms build && dkms instal terhadap kernel baru bekerja tanpa hambatan, namun pacman tidak akan menawarkan informasi apa pun mengapa dkms gagal selama peningkatan kernel (saya menduga itu tidak pernah melewati jalur yang benar dari kernel baru, dan biarkan saja dkms menggunakan default kernel (berjalan saat ini) tetapi dengan versi yang salah).

Anekdot lain tentang ketidakfleksibelannya - seperti dinyatakan, saya terbiasa dengan rpm / yum. Jika saya memiliki file di sistem saya dan saya ingin tahu paket mana yang memilikinya, saya dapat menjalankan yum menyediakan / path / ke / file dan mendapatkan SEMUA paket yang dapat meletakkannya di sana - bahkan jika tidak ada satupun yang diinstal. Jika file itu ditempatkan secara manual, dan sekarang saya ingin menginstal paket - itu akan renamethe yang baru (tambahkan ekstensi .rpmnew), dan biarkan saya memilih apa yang akan digunakan.

pacman hanya kesalahan bahwa file sudah ada, tetapi dengan pesan kesalahan yang sama sekali tidak relevan - itu mengeluh konflik antara pemilik file "benar" dan paket "filesystems" yang saat ini diinstal, seolah-olah itu juga merupakan pemilik dari file yang sama. Juga sebagian besar diarahkan ke informasi yang dipasang lokal - mencoba untuk mendapatkan informasi (seperti daftar file dan kepemilikan) paket yang belum diinstal kurang intuitif.

Sederhananya - itu tidak setua yum, dan mungkin dpkg, yang cocok untuk kemudahan penggunaan juga tidak fleksibel.


1
Singkat dari non-jawaban komprehensif, ada sejumlah poin yang Anda ajukan yang benar-benar merupakan produk yang tidak familier dengan pacman. Sebagai contoh pacman -Qo $fileakan memberi tahu Anda paket apa yang memiliki $ file. Juga, seluruh jawaban Anda adalah stroberi karena OP secara eksplisit meminta perbedaan antara Arch dan Debian - yumtidak ada hubungannya dengan itu ...
jasonwryan

itulah sebabnya saya secara eksplisit mengungkapkan fakta itu di awal jawaban saya. Adapun file -Qo $ - apakah Anda pernah mencobanya untuk paket yang belum diinstal?
Dani_l

Tidak ada gunanya mencobanya untuk paket yang tidak diinstal; ada alat lain untuk itu. Dan pengungkapan tidak mengurangi fakta bahwa Anda belum menjawab pertanyaan: "perbandingan" antara yum dan pacman tidak sama dengan perbedaan antara manajer paket Debian dan Arch.
jasonwryan

@jasonwryan Tentu saja ada benarnya. Hanya karena Anda tidak melihat kebutuhan untuk mencari tahu paket mana yang mungkin memiliki file walaupun itu belum diinstal, tidak berarti kebutuhan seperti itu tidak ada. Itulah intinya. Adapun alat lain - apakah mereka perlu tahu? pacman adalah manajer paket. Mengenai poin utama Anda - Saya mungkin telah salah membaca pertanyaan, tetapi saya berasumsi tentang PM yang ringan vs PM yang lebih kompleks. Saya menganggap apt / dpkg setidaknya sama rumitnya dengan yum / rpm, fitur bijaksana.
Dani_l

Maksud saya adalah Anda menjawab pertanyaan tentang membandingkan apel dengan jeruk dengan membandingkan pemahaman Anda yang terbatas tentang apel dengan pir. Dan ya, Anda benar-benar salah membaca pertanyaan ...
jasonwryan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.