Sự khác biệt trong quản lý gói giữa Debian và Arch

Một cuộc thảo luận từ bài đăng này khiến tôi tò mò về sự khác biệt giữa quản lý gói Debian và Arch. Ngoài ra, mọi người có xu hướng nói rằng Arch rất nhẹ, vì vậy tôi tự hỏi điều đó có liên quan gì đến việc quản lý gói. Có lẽ bởi vì đối xử với Debian Khuyến nghị như phụ thuộc nặng nề bởi mặc định?

Bạn cũng có thể đề cập đến tính linh hoạt / sức mạnh giữa hai người quản lý gói: cái nào trong hai cái cho phép bạn làm nhiều hơn.

Tôi biết rằng một số tính năng khả dụng trên hệ thống quản lý gói Debian sẽ không liên quan trên hệ thống Arch, vì Arch có một Suite và Debian có nhiều (ví dụ như ghim APT và xử lý phụ thuộc nâng cao), vì vậy hãy so sánh các tính năng đó được áp dụng cho cả hai hệ thống (giả sử rằng đối với Debian, tôi chỉ sử dụng không ổn định ).

Tôi chỉ sử dụng vòm thường xuyên trong một vài tuần và không có chuyên gia về chủ đề này nên câu trả lời này không có nghĩa là toàn diện, chỉ một vài điểm tôi đã lưu ý về "tính linh hoạt / sức mạnh":

• Đây chỉ là một ấn tượng nhưng pacman có vẻ hiện đại và đơn giản hơn trong thiết kế / kiến ​​trúc của nó. Ít nhất là có rất ít công cụ để giải quyết. Trong khi tôi không biết về mã nguồn apt, tôi chỉ tình cờ xem mã libalpm (thư viện cơ bản cho pacman) để tạo ra một bản vá rất đơn giản, và nó có vẻ sạch sẽ và dễ hiểu.

• Nó cũng rất nhanh (do tối ưu hóa và cũng có thể bằng cách quan tâm đến một vài điều (xem bên dưới)). Bản phát hành cuối cùng (pacman 3.5, vài ngày tuổi) đã cố gắng cải thiện hiệu suất bằng cách giảm số lượng tệp cơ sở dữ liệu liên quan.

• Mặc dù arch được định hướng theo hướng sử dụng các gói nhị phân, nhưng nó cũng có lợi thế khi xây dựng các gói từ nguồn, với hệ thống xây dựng tương tự như các cổng của BSD (ABS).

• Việc tạo các gói rất dễ dàng và nhanh chóng, chỉ cần một vài dòng trong tệp PKGBUILD và nó đã được thực hiện, không cần phải xử lý kiểm soát / quy tắc / bản quyền / thay đổi / bất cứ điều gì như với các gói Debian. Và trong một vài lần nhấp chuột trên web, gói của bạn được chia sẻ với mọi người trên AUR (Kho lưu trữ người dùng Arch).

Những thứ tôi nhận được trong Debian và không phải trong arch:

• Triggers / hook (điều gì làm cho apt cập nhật bộ đệm biểu tượng, mandb hoặc bất cứ thứ gì chỉ bằng cách xem nơi gói cài đặt tệp, không cần trình đóng gói để làm bất cứ điều gì) (dường như có kế hoạch để thực hiện điều này).

• gỡ lỗi (không có vấn đề gì lớn và bằng cách buộc tôi phải làm mọi thứ theo cách thủ công, nó buộc tôi phải biết chính xác những gì đã được thực hiện) và xử lý đúng cách các tệp cấu hình mới (ít nhất là tôi muốn pacman biết khi nào tệp cấu hình trong gói mới phiên bản khác với phiên bản đã cài đặt vì nó đã được thay đổi trong phiên bản mới hoặc do tôi đã sửa đổi cục bộ).

• ký gói (có vẻ như nó đang được thực hiện ).

Đối với vòm là ánh sáng, lý do thực sự duy nhất là nó đi kèm với một vài gói được cài đặt theo mặc định và bạn được khuyến khích thêm những gì bạn cần, vì vậy có lẽ không cài đặt các phụ thuộc tùy chọn theo mặc định là kích thích người dùng cài đặt tránh phình to.

Tôi bắt đầu hành trình Linux của mình với Ubuntu lucid và hiện đang sử dụng Arch. Tôi đã viết một số gói Arch và tôi sẽ nói nó dễ hơn nhiều so với việc viết các gói Debian. Nhưng, tôi muốn chỉ ra cho @gentledevil rằng Arch có một hệ thống móc cho các gói, được gọi là một install file.

Về cơ bản, nó được đặt tên ${pkgname}.installvà chứa một vài chức năng để cài đặt / gỡ bỏ / nâng cấp trước / sau; chỉ cần đặt các bản cập nhật bộ đệm phông chữ của bạn vào đó và cứ thế và nó hoạt động tương tự như các móc Debian.

Ngoài ra, tôi nhận thấy bạn đã đề cập đến việc 'ghim' một ứng dụng bằng các công cụ quản lý gói debian; Archman pacman cũng tích hợp sẵn, /etc/pacman.confchấp nhận một số cài đặt, bao gồm IgnorePkg =, điều này sẽ ngăn nâng cấp lên bất kỳ gói nào được liệt kê sau bằng (phân cách bằng dấu cách)

Trước khi tôi đi quá xa, hãy nghiên cứu Dòng thời gian của tượng hình Linux

Để hiểu sự khác biệt trong Trình quản lý gói, bạn phải hiểu các triết lý của HĐH được mô tả ở trên

Ba phụ huynh lớn

1. Redhat, Now Fedora - Gói Manger - RPM, viết tắt của Redhat Gói Manager, dòng lệnh rpm
2. Slackware - Trình quản lý gói - tgz, các tệp nén thông thường. Mặc dù đây chỉ là các tệp nén, tệp được Slackware xây dựng ngược dòng và được đặt trong kho lưu trữ, đôi khi được gọi là cổng
3. Debian - DEB, viết tắt của Debian, công cụ dòng lệnh của nó là Aptitude or Apt

Những phụ huynh này là những người mẹ và người cha của hầu hết các bản phân phối mà chúng ta biết ngày nay. Ý tưởng / khái niệm về Hệ thống quản lý gói được bắt nguồn hoặc chia sẻ dưới một hình thức hoặc thời trang nào đó. Bất kể, tất cả các bậc cha mẹ này đều là nhà phân phối nhị phân, nghĩa là chương trình được đóng gói và quyết định bởi bên thứ 3, sau đó được lưu trữ trong kho lưu trữ và được sử dụng hoặc cài đặt bởi cơ sở người dùng.

3 cha mẹ nhỏ

1. Linux From Scratch - Dựa trên nguồn, không có trình quản lý gói.
2. Gentoo - Bắt nguồn từ Linux từ Scratch . Bản phân phối này thực chất là Linux từ Scratch cộng với trình quản lý gói, được gọi là Portage / emerge
3. SourceMage - Gói quản lý phù thủy

Những phụ huynh này là trẻ vị thành niên vì cơ sở người dùng của họ giao dịch tốc độ và dễ cài đặt với sức mạnh và dễ cấu hình. Mỗi gói được tải xuống và biên dịch từ đầu, sử dụng các biến và tệp cấu hình.

Cây cầu

Arch được tạo ra như một cầu nối giữa một phân phối nhị phân, giống như một trong 3 Cha mẹ chính và phân phối dựa trên nguồn giống như một trong 3 Cha mẹ nhỏ. Như vậy, nó nhận được trạng thái là cha mẹ trong dòng thời gian, bởi vì không có cha mẹ nào khác cung cấp chức năng này. Pacman có thể linh hoạt cho phép người dùng cài đặt gói nhị phân từ kho lưu trữ chính thức hoặc gói được xây dựng tùy chỉnh bằng Arch Build System. Khái niệm này cung cấp một sự cân bằng giữa sức mạnh mà cha mẹ nhỏ cung cấp với sự dễ dàng cài đặt mà cha mẹ chính cung cấp.

Theo tôi, đó không phải là trình quản lý gói thể hiện sức mạnh của một hệ thống, vì tất cả các trình quản lý gói đều thực hiện cùng một nhiệm vụ, đó là quản lý và duy trì một hệ thống lành mạnh. Do đó, hệ thống bạn sử dụng phải được xác định bởi các yếu tố như:

• Cấp độ người dùng: Một người mới sử dụng linux nên bắt đầu với Major Parent, trong khi một người thành thạo về mặt kỹ thuật sẽ tìm thấy sự cân bằng.
• Những gì bạn muốn làm với hệ thống của mình: Chạy máy chủ LAMP với người dùng được đính kèm hoàn toàn khác với chạy máy tính để bàn để duyệt web và đọc e-mail.
• Mức độ thoải mái: Cấp độ người dùng không chịu được, nếu bạn thành thạo về mặt kỹ thuật, nhưng không muốn dành một ngày cuối tuần để biên dịch một hệ thống, bạn sẽ chọn một phụ huynh chính, bất kể mọi người bạn biết có chọn cái gì khác không.

Đây không phải là một câu trả lời đầy đủ hay toàn diện - những áp phích trước tôi đã đưa ra một số điểm rất tốt, tôi chỉ muốn thêm 2 xu của mình. Một điều nữa - tôi chưa bao giờ thực sự quen với apt / dpkg. Nó luôn có vẻ quá phức tạp đối với tôi, tôi thực sự thoải mái nhất với yum / vòng / phút.

pacman rất dễ sử dụng, đó là một pro và một con - bạn có thể học cách sử dụng nó (xây dựng gói sang một bên) trong một buổi chiều - nó sử dụng các tính năng quản lý gói hoàn toàn trực quan và hoàn chỉnh, nhưng - và đây là một nhưng lớn - nó là vô cùng không linh hoạt.

Nếu các nhà thiết kế không nghĩ đến một tính năng trước đó, bạn sẽ bị lừa.

Một vài ví dụ: không có phiên bản gốc trong pacman. Nếu bạn muốn hạ cấp phiên bản gói - bạn phải tải xuống phiên bản gói cụ thể đó và sử dụng tùy chọn -U (nâng cấp) để cài đặt từ tệp. Nó rất hướng đến việc luôn luôn sử dụng các gói tiên tiến trên hệ thống của bạn.

Không có dọn dẹp bộ đệm nội bộ thực sự / xây dựng lại hoàn chỉnh. Nếu (do sự cố mạng), quá trình tải xuống gói bị hỏng, ví dụ như trong -Syu, thông báo lỗi, trong khi chính xác, sẽ không được sử dụng nhiều - nó sẽ không xác định chính xác gói bị hỏng ngay cả khi đã xác minh và gỡ lỗi "đầy đủ" và không có số lượng -Syyc sẽ thực sự xóa bộ nhớ cache và tải lại các gói. Tin vui là -Sc sẽ cho bạn biết các gói đã tải xuống ở đâu để bạn có thể chỉ cần loại bỏ gói vi phạm (nếu bạn có thể tìm ra gói nào) hoặc tất cả chúng và khởi động lại -Syu.

Tích hợp pacman với dkms cũng có chút vấn đề - trong khi cài đặt kernel mới tôi vẫn gặp lỗi từ dkms. Sử dụng dkms build && dkms cài đặt vào kernel mới hoạt động mà không gặp trở ngại nào, tuy nhiên pacman sẽ không cung cấp thông tin nào tại sao dkms thất bại trong quá trình nâng cấp kernel (tôi nghi ngờ nó không bao giờ vượt qua đường dẫn chính xác của kernel mới và chỉ để dkms sử dụng mặc định (hiện đang chạy) kernel nhưng với phiên bản sai).

Một giai thoại khác về tính không linh hoạt của nó - như đã nêu, tôi đã quen với vòng / phút. Nếu tôi có một tệp trên hệ thống của mình và tôi muốn biết gói nào sở hữu nó, tôi có thể chạy yum cung cấp / path / to / file và nhận TẤT CẢ các gói có thể đặt nó ở đó - ngay cả khi không có gói nào được cài đặt. Nếu tệp được đặt thủ công và bây giờ tôi muốn cài đặt một gói - nó sẽ đổi tên mới (thêm phần mở rộng .rpmnew) và để tôi chọn sử dụng cái gì.

pacman chỉ đơn giản là lỗi một tệp đã tồn tại, nhưng với thông báo lỗi hoàn toàn không liên quan - nó phàn nàn về xung đột giữa chủ sở hữu tệp "đúng" và gói "hệ thống tệp" hiện được cài đặt, như thể nó cũng là chủ sở hữu của cùng một tệp. Ngoài ra, nó chủ yếu hướng đến thông tin được cài đặt cục bộ - cố gắng lấy thông tin (như danh sách tệp và quyền sở hữu) của các gói chưa được cài đặt là ít trực quan hơn.

Nói một cách đơn giản - nó không chín chắn như yum, và có lẽ là dpkg, điều này cho phép nó dễ sử dụng cũng như tính không linh hoạt tương đối.