Những ưu / nhược điểm của deb so với vòng / phút là gì?

Vì bất kỳ lý do gì, tôi luôn sử dụng các bản phân phối dựa trên RPM (Fedora, Centos và hiện đang mở). Tôi thường nghe nói rằng deb tốt hơn vòng / phút, nhưng khi được hỏi tại sao, chưa bao giờ có thể có được câu trả lời mạch lạc (thay vào đó thường nhận được một số lời ca ngợi nhiệt tình và số lượng rất lớn của spittle).

Tôi hiểu có thể có một số lý do lịch sử, nhưng đối với các bản phân phối hiện đại sử dụng hai phương pháp đóng gói khác nhau, bất kỳ ai cũng có thể đưa ra các giá trị kỹ thuật (hoặc khác) của cái này so với cái kia?

Sự khác biệt chính cho một người duy trì gói (tôi nghĩ đó sẽ là 'nhà phát triển' trong biệt ngữ Debian) là cách thức siêu dữ liệu gói và các tập lệnh đi kèm kết hợp với nhau.

Trong thế giới RPM, tất cả các gói của bạn (RPM bạn duy trì) được đặt trong một cái gì đó như ~/rpmbuild. Bên dưới, có SPECthư mục cho các tệp spec của bạn, SOURCESthư mục cho tarball nguồn RPMSvà SRPMSthư mục để đặt RPM và SRPM mới được tạo vào và một số thứ khác hiện không liên quan.

Mọi thứ liên quan đến cách tạo ra RPM đều có trong tệp spec: tệp vá nào sẽ được áp dụng, có thể trước và sau tập lệnh, siêu dữ liệu, thay đổi, mọi thứ. Tất cả các tarball nguồn và tất cả các bản vá của tất cả các gói của bạn đều ở NGUỒN.

Bây giờ, cá nhân tôi, tôi thích thực tế là mọi thứ đều đi vào tệp spec và tệp spec đó là một thực thể riêng biệt với tarball nguồn, nhưng tôi không quá nhiệt tình về việc có tất cả các nguồn trong SOURCES. IMHO, NGUỒN bị lộn xộn khá nhanh và bạn có xu hướng mất dấu vết của những gì trong đó. Tuy nhiên, ý kiến ​​khác nhau.

Đối với RPM, điều quan trọng là sử dụng tarball chính xác giống như một dự án ngược dòng phát hành, cho đến dấu thời gian. Nói chung, không có ngoại lệ cho quy tắc này. Các gói Debian cũng yêu cầu tarball giống như ngược dòng, mặc dù chính sách Debian yêu cầu một số tarball được đóng gói lại (cảm ơn, Umang).

Các gói Debian có một cách tiếp cận khác. (Tha thứ cho bất kỳ sai lầm nào ở đây: Tôi ít có kinh nghiệm hơn với deb của tôi với RPM.) Các tệp phát triển của các gói Debian được chứa trong một thư mục trên mỗi gói.

Những gì tôi (nghĩ) thích về cách tiếp cận này là thực tế là tất cả mọi thứ được chứa trong một thư mục duy nhất.

Trong thế giới Debian, việc mang các bản vá lỗi trong một gói không phải là (chưa) ngược dòng được chấp nhận hơn một chút. Trong thế giới RPM (ít nhất là trong số các công cụ phái sinh của Red Hat), điều này được tán thành. Xem "FedoraProject: Gần các dự án thượng nguồn" .

Ngoài ra, Debian có một số lượng lớn các tập lệnh có thể tự động hóa một phần rất lớn trong việc tạo gói. Ví dụ: tạo một gói - đơn giản - của chương trình Python được thiết lập, cũng đơn giản như tạo một vài tệp dữ liệu meta và chạy debuild. Điều đó nói rằng, tệp đặc tả cho gói như vậy ở định dạng RPM sẽ khá ngắn và trong thế giới RPM cũng vậy, có rất nhiều thứ được tự động hóa ngày nay.

Rất nhiều người so sánh với cài đặt phần mềm apt-getđể rpm -i, và do đó nói DEB tốt hơn. Điều này tuy nhiên không có gì để làm với định dạng tệp DEB. Sự so sánh thực sự là dpkgvs rpmvà aptitude/ apt-*vs zypper/ yum.

Từ quan điểm của người dùng, không có nhiều sự khác biệt trong các công cụ này. Các định dạng RPM và DEB đều chỉ là các tệp lưu trữ, với một số siêu dữ liệu được đính kèm. Cả hai đều phức tạp như nhau, có đường dẫn cài đặt được mã hóa cứng (yuck!) Và chỉ khác nhau về các chi tiết tinh tế. Cả hai dpkg -ivà rpm -ikhông có cách nào để tìm ra cách cài đặt các phụ thuộc, trừ khi chúng được chỉ định trên dòng lệnh.

Trên đầu trang của các công cụ này, có quản lý kho lưu trữ ở dạng apt-...hoặc zypper/ yum. Các công cụ này tải xuống kho lưu trữ, theo dõi tất cả siêu dữ liệu và tự động tải xuống các phụ thuộc. Việc cài đặt cuối cùng của mỗi gói duy nhất được bàn giao cho các công cụ cấp thấp.

Trong một thời gian dài, apt-getđã vượt trội trong việc xử lý số lượng siêu dữ liệu khổng lồ thực sự nhanh chóng trong khi yumsẽ mất nhiều thời gian để làm điều đó. RPM cũng bị các trang web như rpmfind, nơi bạn sẽ tìm thấy hơn 10 gói không tương thích cho các bản phân phối khác nhau. Apthoàn toàn che giấu vấn đề này cho các gói DEB vì tất cả các gói đã được cài đặt từ cùng một nguồn.

Theo tôi, zypperđã thực sự thu hẹp khoảng cách aptvà không có lý do gì phải xấu hổ khi sử dụng phân phối dựa trên RPM trong những ngày này. Thật tuyệt nếu không dễ sử dụng hơn với dịch vụ xây dựng openSUSE trong tay cho một chỉ số gói tương thích lớn.

Từ quan điểm của quản trị viên hệ thống, tôi đã tìm thấy một vài khác biệt nhỏ, chủ yếu là trong bộ công cụ dpkg / vòng / phút thay vì định dạng gói.

• dpkg-divertlàm cho nó có thể có tập tin của riêng bạn thay thế tập tin đến từ một gói. Nó có thể là cứu cánh khi bạn có một chương trình tìm kiếm một tập tin trong /usrhoặc /libsẽ không có /usr/localcâu trả lời. Ý tưởng đã được đề xuất, nhưng theo như tôi có thể nói không được thông qua, trong vòng / phút.

• Khi tôi quản lý các hệ thống dựa trên vòng / phút cuối cùng (được thừa nhận là cách đây nhiều năm, có thể tình hình đã được cải thiện), vòng / phút sẽ luôn ghi đè lên các tệp cấu hình đã sửa đổi và chuyển các tùy chỉnh của tôi vào *.rpmsave(IIRC). Điều này đã làm cho hệ thống của tôi không thể khởi động ít nhất một lần. Dpkg hỏi tôi phải làm gì, với việc giữ các tùy chỉnh của tôi làm mặc định.

• Gói nhị phân vòng / phút có thể khai báo các phụ thuộc vào tệp chứ không phải gói, cho phép kiểm soát tốt hơn gói gỡ lỗi.

• Bạn không thể cài đặt gói phiên bản N vòng / phút trên hệ thống với phiên bản N-1 của công cụ vòng / phút. Điều đó cũng có thể áp dụng cho dpkg, ngoại trừ định dạng không thay đổi thường xuyên.

• Cơ sở dữ liệu dpkg bao gồm các tệp văn bản. Cơ sở dữ liệu vòng / phút là nhị phân. Điều này làm cho cơ sở dữ liệu dpkg dễ dàng điều tra và sửa chữa. Mặt khác, miễn là không có gì sai, vòng / phút có thể nhanh hơn rất nhiều (cài đặt một bản deb yêu cầu đọc hàng ngàn tệp nhỏ).

• Một gói deb sử dụng định dạng chuẩn ( ar, tar, gzip), do đó bạn có thể kiểm tra, và trong một tinh chỉnh nhúm) gói deb một cách dễ dàng. Các gói Rpm gần như không thân thiện.

RPM:

• 'Chuẩn hóa' (không phải là không có thông số kỹ thuật)
• Được sử dụng bởi nhiều bản phân phối khác nhau (nhưng các gói từ cái này không nhất thiết phải hoạt động trên cái khác)
• IIRC cho phép phụ thuộc vào tệp, không chỉ trên các gói

DEB:

• Ngày càng phổ biến
• Cho phép đề xuất và đề xuất (có thể RPM mới hơn cũng cho phép)

Có lẽ câu hỏi quan trọng hơn là trình quản lý gói (dpkg so với yum so với aptitude, v.v.) chứ không phải định dạng gói (vì cả hai đều có thể so sánh được).

Như một số người trả lời đã nói, không quá nhiều khi một định dạng gói nhất định rõ ràng là vượt trội. Về mặt kỹ thuật, chúng có thể ít nhiều có thể so sánh được. Từ quan điểm của tôi, rất nhiều sự khác biệt và tại sao mọi người thích cái này hơn cái kia, phải làm với:

• Triết lý của thiết kế gói ban đầu và đối tượng mục tiêu
• Quy mô cộng đồng, và bằng cách mở rộng, chất lượng và sự phong phú của các kho lưu trữ

Triết học:

Trong thế giới Ubuntu / Debian / Mint / ..., người dùng mong đợi gói được cài đặt sẽ "chỉ hoạt động" sau khi được cài đặt. Điều này có nghĩa là trong quá trình cài đặt, các gói được dự kiến ​​sẽ chăm sóc mọi thứ cần thiết để thực sự làm cho chúng chạy tốt, bao gồm nhưng không giới hạn ở:

• thiết lập các công việc cần thiết hoặc tùy chọn
• thiết lập các lựa chọn / bí danh
• thiết lập các kịch bản khởi động / tắt máy
• bao gồm tất cả các tệp cấu hình cần thiết với mặc định có ý nghĩa
• giữ các phiên bản cũ của thư viện và thêm các liên kết tượng trưng được phiên bản phù hợp vào thư viện (.so) để tương thích ngược
• hỗ trợ sạch cho các nhị phân đa vòm (32 và 64 bit) trên cùng một máy, v.v.

Trong thế giới vòng / phút - phải thừa nhận rằng đây là tình huống vài năm trước và nó có thể đã được cải thiện kể từ đó - tôi thấy mình phải chạy các bước bổ sung (ví dụ: chkconfig, cho phép các công việc cron) thực sự làm cho các gói thực sự hoạt động. Điều này có thể ổn đối với các sysadins hoặc những người am hiểu về Unix, nhưng nó khiến những người mới trải nghiệm phải chịu đựng. Lưu ý rằng không phải chính định dạng gói RPM ngăn chặn điều này xảy ra, chỉ là nhiều gói không thực sự được "thực hiện đầy đủ" từ quan điểm của một người mới.

Quy mô cộng đồng, sự tham gia và sự phong phú của các kho lưu trữ:

Vì cộng đồng ubfox / debian / mint / ... lớn hơn, nhiều người hơn tham gia vào phần mềm đóng gói và thử nghiệm. Tôi thấy sự phong phú và chất lượng của các kho lưu trữ là vượt trội. Trong Ubuntu, tôi hiếm khi, nếu cần, phải tải xuống nguồn và xây dựng từ nó. Khi tôi chuyển từ Red Hat sang Ubuntu tại nhà, repo RHEL điển hình có ~ 3000 gói trong đó, đồng thời, ubfox + vũ trụ + đa vũ trụ có sẵn trực tiếp từ bất kỳ máy Canonical nào, có ~ 30.000 gói (khoảng 10 lần). Hầu hết các gói tôi đang tìm kiếm ở định dạng RPM, không thể truy cập dễ dàng thông qua tìm kiếm đơn giản và nhấp vào trình quản lý gói. Họ yêu cầu chuyển sang các kho lưu trữ thay thế, tìm kiếm trang web dịch vụ rpmfind, v.v. Điều này, trong hầu hết các trường hợp, thay vì giải quyết vấn đề, đã phá vỡ cài đặt của tôi bằng cách không giới hạn những gì phụ thuộc có thể hoặc không thể nâng cấp chính xác. Tôi đánh vào hiện tượng "địa ngục phụ thuộc", như được mô tả ở trên bởi Shawn J. Goff.

Ngược lại trong Ubuntu / Debian tôi thấy rằng tôi gần như không bao giờ cần phải xây dựng từ nguồn. Cũng vì:

• Chu kỳ phát hành Ubuntu nhanh (6 tháng)
• Sự tồn tại của PPA tương thích hoàn toàn hoạt động ra khỏi hộp
• Các kho lưu trữ nguồn đơn (tất cả được lưu trữ bởi Canonical) không cần tìm kiếm các kho thay thế / bổ sung
• Trải nghiệm người dùng liền mạch từ nhấp để chạy

Tôi chưa bao giờ phải thỏa hiệp với các phiên bản cũ hơn của các gói tôi quan tâm, ngay cả khi chúng không được các nhà phát triển chính thức (Canonical) duy trì. Tôi không bao giờ phải rời khỏi trình quản lý gói GUI thân thiện yêu thích của mình để thực hiện tìm kiếm thuận tiện theo từ khóa, để tìm và cài đặt bất kỳ gói nào tôi muốn. Ngoài ra, một vài lần tôi đã cài đặt các gói debian (không phải Canonical) trên Ubuntu và chúng hoạt động rất tốt, mặc dù khả năng tương thích này không được đảm bảo chính thức.

Lưu ý rằng điều này không có ý định bắt đầu một cuộc chiến rực lửa, nó chỉ là chia sẻ kinh nghiệm của tôi khi sử dụng song song cả hai thế giới trong vài năm (làm việc so với nhà).

Tôi nghĩ rằng sự thiên vị không đến từ định dạng gói, mà đến từ sự không nhất quán từng tồn tại trong kho của RedHat.

Quay lại khi RedHat là một bản phân phối (trước thời của RHEL, Fedora và Fedora Core), đôi khi mọi người sẽ thấy mình trong "Địa ngục RPM" hoặc "Địa ngục phụ thuộc". Điều này xảy ra khi một kho lưu trữ sẽ kết thúc với một gói có phần phụ thuộc (sâu vài lớp, thường), loại trừ lẫn nhau. Hoặc nó sẽ phát sinh khi hai gói khác nhau có hai phụ thuộc loại trừ lẫn nhau. Đây là một vấn đề với trạng thái của kho lưu trữ, không phải với định dạng gói. "Địa ngục RPM" đã gây ra sự khó chịu cho các hệ thống RPM trong số một số người dùng Linux đã bị đốt cháy bởi vấn đề này.

Ngoài ra còn có sự khác biệt "triết học" trong đó trong các gói Debian bạn có thể đặt câu hỏi và bằng cách này, chặn quá trình cài đặt. Mặt xấu của điều này là một số gói sẽ chặn nâng cấp của bạn cho đến khi bạn trả lời. Mặt tốt của điều này, cũng là một sự khác biệt về mặt triết học, trên các hệ thống dựa trên Debian, khi một gói được cài đặt, nó được cấu hình (không phải lúc nào cũng như bạn muốn) và chạy. Không phải trên Redhat dựa trên các hệ thống mà bạn cần tạo / sao chép từ / usr / share / doc / * một tệp cấu hình mặc định / mẫu.

Một điều tôi thích về RPM là sự bổ sung (gần đây?) Của RPM delta. Điều này cho phép cập nhật dễ dàng hơn, giảm băng thông cần thiết.

DEB là các tệp ar tiêu chuẩn (bên trong có nhiều tài liệu lưu trữ tiêu chuẩn hơn), RPM là các tệp nhị phân "độc quyền". Cá nhân tôi nghĩ rằng trước đây là thuận tiện hơn.

Chỉ cần hai điều tôi có thể nghĩ ra khỏi đỉnh đầu của tôi. Cả hai đều rất so sánh. Cả hai đều có công cụ tuyệt vời để đóng gói. Tôi không nghĩ rằng có rất nhiều công đức cho nhau hay ngược lại.

Dịch vụ xây dựng openSUSE (OBS) và zypper là một vài lý do tôi thích RPM hơn là tranh luận từ quan điểm của người đóng gói và người dùng. Zypper đã đi được một chặng đường dài và khá nhanh. OBS, mặc dù nó có thể xử lý các cuộc tranh luận, nhưng thực sự tốt khi đóng gói rpms cho các nền tảng khác nhau như openSUSE, SLE, RHEL, centos, fedora, mandriva, v.v.

Các gói Debian có thể bao gồm kích thước được cài đặt , nhưng tôi không tin RPM có trường tương đương. Nó có thể được tính toán dựa trên các tệp có trong gói, nhưng cũng không thể dựa vào vì các hành động có thể được thực hiện trong các tập lệnh cài đặt trước / sau.

Dưới đây là một tài liệu tham khảo khá tốt để so sánh một số tính năng cụ thể có sẵn cho từng định dạng đóng gói cụ thể: http://debian-br.sourceforge.net/txt/alien.htmlm (theo máy chủ web, tài liệu đó khá cũ : Sửa đổi lần cuối: Chủ nhật, ngày 15 tháng 10 năm 2000 nên đây có thể không phải là tài liệu tham khảo tốt nhất.)

Đối với Gói Debian có một tập hợp lớn các tập lệnh trợ giúp, hướng dẫn chính sách nhất quán và ít nhất một cách để thực hiện hầu hết mọi thứ. Sự phụ thuộc được xử lý rất tốt và có thể được xác định ở mức độ chi tiết rất tốt. Xây dựng lại các gói rất dễ dàng với các gói debian và được hỗ trợ tốt bởi các công cụ có sẵn.

Không có câu trả lời nào khác chạm vào làm thế nào ba khác biệt cơ bản sau đây có hậu quả thực sự:

1. debtập tin về cơ bản chỉ là artài liệu lưu trữ chứa hai tarball nén
2. debcác gói và dpkghệ thống lưu trữ các tập lệnh bảo trì của bạn dưới dạng các tệp riêng biệt
3. dpkgvà rpmchạy các kịch bản bảo trì theo một thứ tự khác trong quá trình nâng cấp.

Cùng với nhau, những khác biệt này đã giúp tôi dễ dàng khắc phục các sự cố do các gói xấu gây ra và làm cho các gói hoạt động theo cách tôi cần, trên debcác hệ thống dựa trên các hệ thống trên rpmcơ sở, cả với tư cách là quản trị viên hệ thống và đóng gói .

Vì số 1, nếu tôi cần thay đổi một debtệp, tôi có thể mở nó một cách tầm thường, thực hiện bất kỳ thay đổi nào tôi muốn và đóng gói lại, sử dụng các công cụ tiêu chuẩn tồn tại trên hầu hết các hệ thống .

Điều này bao gồm thay đổi / thêm / xóa bất kỳ phụ thuộc nào, hoặc bất kỳ tệp gói nào, hoặc bất kỳ tập lệnh bảo trì nào, hoặc thay đổi phiên bản hoặc tên gói.

Vì # 2, nếu có sự cố trong tập lệnh "xóa" được cài đặt bởi gói đã được cài đặt , tôi có thể sửa chữa nó một cách tầm thường, sử dụng các công cụ tiêu chuẩn tồn tại trên bất kỳ hệ thống nào .

Vì số 3, tôi có thể thực hiện một số sửa lỗi đó chỉ bằng cách phát hành phiên bản mới của gói, vì trong quá trình nâng cấp, dpkgchạy tập lệnh "cài đặt sẵn" của phiên bản mới của gói trước tập lệnh "xóa sau" phiên bản cũ.

Điều này có nghĩa là diện tích bề mặt để vi phạm "nguyên tắc phục hồi" nhỏ hơn trong debcác gói: nhiều lỗi trong phiên bản trước của gói có thể được phục hồi từ phiên bản mới.

Và vì việc sửa đổi gói rất dễ dàng - chi phí kiến ​​thức và chi phí cụ thể của gói thực tế rất nhỏ - nó có thể truy cập được với nhiều người hơn và tốn ít thời gian và công sức hơn, với debcác tệp.