RPM (phần mềm)

RPM Package Manager (RPM)
Thiết kế bởiErik Troan, Marc Ewing,[1] Red Hat
Phát triển bởiCộng đồng & Red Hat
Phát hành lần đầu1997; 27 năm trước (1997)[1]
Phiên bản ổn định
4.13 / 5/8/2015; 17 tháng trước (2015-08-05)
Kho mã nguồn
Viết bằngC, Perl[2]
Hệ điều hànhLinux, Tương tự Unix
Thể loạiPackage management system
Giấy phépGPL
Websitewww.rpm.org

RPM Package Manager (RPM) (ban đầu là Red Hat Package Manager; bây giờ là một từ viết tắt đệ quy) là một trình quản lý gói.[3] Tên gọi RPM đề cập đến: định dạng file.rpm, file có định dạng file.rpm, phần mềm đóng gói file, và chương trình quản lý gói của chính nó. RPM được thiết kế chủ yếu cho các bản phân phối Linux; định dạng tập tin là định dạng gói cơ bản của Linux Standard Base.

Mặc dù nó đã được tạo ra để sử dụng trong Red Hat Linux, RPM hiện được sử dụng trong nhiều bản phân phối Linux.  Nó cũng đã được chuyển sang một số hệ điều hành khác, chẳng hạn như Novell NetWare (các phiên bản 6.5 SP3) và AIX của IBM (các phiên bản 4).

Một gói RPM có thể chứa một thiết lập tùy ý của các tập tin. Phần lớn các tập tin RPM gặp phải là “RPM nhị phân” (hay BRPMs) có chứa các phiên bản biên dịch của một số phần mềm. Ngoài ra còn có “source RPMs” (hay SRPMs) chưa các file mã nguồn được sử dụng để đóng gói. Chúng có một từ khóa thích hợp trong phần đầu tập mà phân biệt chúng với (B)RPM bình thường, khiến chúng bị tách ra vào /usr/src khi cài đặt. SRPMS có phần mở rộng file".src.rpm" (.spm trên hệ thống file giới hạn 3 ký tự mở rộng, ví dụ DOS FAT trước đây).

Lịch sử

[sửa | sửa mã nguồn]

RPM ban đầu được viết vào năm 1997 bởi Erik Troan và Marc Ewing, dựa trên các kinh nghiệm pms, rpp, và pm experiences. pm được viết bởi Rik Faith và Doug Hoffman tháng 5/1995 cho Red Hat Software, thiết kế và triển khai thực hiện của nó ảnh hưởng rất lớn từ pms, một hệ thống quản lý gói được viết bởi Faith và Kevin Martin vào mùa thu năm 1993 cho Bogus Linux Distribution. pm bảo tồn mô hình "Pristine Sources + patches"của pms, trong khi bổ sung các tính năng và loại bỏ những hạn chế có mặt trong việc thực hiện. pm cung cấp nhiều hỗ trợ tăng cường cơ sở dữ liệu để theo dõi và kiểm tra các gói cài đặt[4][5]

Tính năng

[sửa | sửa mã nguồn]

 Đối với một quản trị viên hệ thống thực hiện cài đặt phần mềm và bảo trì, việc sử dụng các phần mềm quản lý chứ không phải cài đặt  thủ công có những lợi thế như đơn giản, nhất quán và khả năng cho các quá trình này tự động và không tương tác.

Các tính năng của RPM bao gồm:

  • Các gói RPM có thể được xác minh mã hóa với GPG và MD5
  • Lưu trữ mã nguồn gốc(e.g. .tar.gz, .tar.bz2) có trong SRPMS,khiến dễ xác minh hơn
  • PatchRPMs và DeltaRPMs, RPM tương đương với một tập tin vá lỗi, từng bước có thể cập nhật phần mềm được cài đặt RPM
  • Automatic build-time dependency evaluation.

Local operations

[sửa | sửa mã nguồn]

Gói có thể đến từ bên trong một phân phối cụ thể (ví dụ như Red Hat Enterprise Linux) hoặc được xây dựng cho nó bởi các bên khác (ví dụ RPM Fusion cho Fedora).[6] Phụ thuộc chéo giữa các RPM phụ thuộc lẫn nhau (được gọi là "phụ thuộc địa ngục") có thể có vấn đề;[7] trong trường hợp này là một lệnh cài đặt duy nhất cần phải xác định tất cả các gói có liên quan.

Kho lưu trư

[sửa | sửa mã nguồn]

RPM thường được thu gom tập trung về một hoặc nhiều kho lưu trữ trên internet. Một site thường có một kho lưu trữ RPM của riêng mình và có thể hoạt động như một mirrors địa phương của một kho lưu trữ trên internet hoặc là bộ sưu tập được duy trì tại địa phương của RPM hữu ích.

Front ends

[sửa | sửa mã nguồn]

Một số front-ends để RPM giảm bớt quá trình thu thập và cài đặt RPM từ kho và giúp đỡ trong việc giải quyết phụ thuộc của họ. Bao gồm các:

Cơ sở dữ liệu cài đặt RPM cục bộ

[sửa | sửa mã nguồn]

Hoạt động phía sau người quản lý gói là cơ sở dữ liệu RPM, lưu trữ trong /var/lib/rpm. Nó dùng  Berkeley DB làm back-end của nó. Nó bao gồm một cơ sở dữ liệu duy nhất (trọn gói) có chứa tất cả metadata của file cài đặt RPM. Nhiều cơ sở dữ liệu được tạo ra cho mục đích lập chỉ mục, sao chép dữ liệu để tăng tốc độ truy vấn. Các cơ sở dữ liệu được sử dụng để theo dõi tất cả các tập tin được thay đổi và tạo ra khi một người sử dụng (dùng RPM) cài đặt một gói, do đó cho phép người sử dụng (thông qua RPM) để đảo ngược những thay đổi và loại bỏ các gói sau đó.Nếu cơ sở dữ liệu bị hỏng (có thể nếu RPM client bị killed), các cơ sở dữ liệu chỉ mục có thể được tái tạo bằng lệnh rpm --rebuilddb.[10]

Miêu tả

[sửa | sửa mã nguồn]

Trong khi định dạng RPM là như nhau trên các bản phân phối Linux khác nhau, quy ước chi tiết và hướng dẫn có thể khác nhau giữa chúng.

Tên file và nhãn của các gói

[sửa | sửa mã nguồn]

Một RPM được phân phối trong một tập tin duy nhất, thường là trong các định dạng:

<name>-<version>-<release>.<architecture>.rpm

ví dụ như:

libgnomeuimm-2.0-2.0.0-3.i386.rpm

where <name> is libgnomeuimm, <version> is 2.0, <release> is 2.0.0-3, and <architecture> is i386.

Mã nguồn cũng có thể được phân phối trong các gói RPM trong trường hợp đó <architecture> được quy định như src as in, libgnomeuimm-2.0-2.0.0-3.src.rpm

RPM với phần mở rộng noarch.rpm tham khảo các gói mà không phụ thuộc vào kiến trúc của một máy tính nào đó. Chúng bao gồm đồ họa và văn bản cho một chương trình khác để sử dụng, và các chương trình viết bằng ngôn ngữ lập trình thông dịch như các chương trình Python và shell scripts.

Nội dung RPM cũng bao gồm một package label, chứa các mảnh thông tin sau đây:

  • tên phần mềm
  • phiên bản phần mềm (phiên bản lấy từ nguồn ngược dòng gốc của phần mềm)
  • phát hành gói (số lần các gói đã được built lại bằng cách sử dụng cùng một phiên bản của phần mềm). Trường này cũng thường được sử dụng để chỉ ra sự phân bố cụ thể các gói cho bằng cách thêm các chuỗi như "mdv" (trước đây là, "mdk") (Mandriva Linux), "mga" (Mageia), "fc4" (Fedora Core 4), "rhl9" (Red Hat Linux 9), "suse100" (SUSE Linux 10.0)...
  • kiến trúc của gói khi built (i386, i686, x86_64, ppc,...)

Các trường label không cần phải phù hợp với tên tập tin.

Thư viện đóng gói

[sửa | sửa mã nguồn]

Thư viện được phân phối trong hai gói riêng biệt cho mỗi phiên bản. Một chứa mã biên dịch sẵn để sử dụng run-time, trong khi cái thứ hai có chứa các tập tin phát triển liên quan như tiêu đề... Những gói có "-devel" nối vào trong tên. Các quản trị viên hệ thống phải đảm bảo rằng các phiên bản của hệ nhị phân và các gói phát triển phù hợp.

Định dạng

[sửa | sửa mã nguồn]

Định dạng nhị phân và bao gồm bốn phần:

  • Lead, trong đó xác định các tập tin như một tập tin RPM và chứa nhiều header dư thừa.
  • Chữ ký, có thể được sử dụng để đảm bảo tính toàn vẹn và/hoặc tính xác thực.
  • Header, chứa metadata bao gồm tên gói, phiên bản, kiến trúc, danh sách tập tin...
  • Một kho lưu trữ tập tin (payload), mà thường là ở định dạng cpio, nén với gzip. Các công cụ rpm2cpio cho phép thu hồi các tập tin cpio mà không cần phải cài đặt gói RPM.[11]
    • Các phiên bản gần đây của RPM cũng có thể sử dụng kiểu nén bzip2, lzip,[12] lzma, hoặc xz..
    • Định dạng RPM 5.0 hỗ trợ sử dụng  chuẩn nén xar.

Các "Recipe" để tạo ra một gói RPM là một file spec. File Spec có phần mở rộng ".spec" và chứa tên gói, phiên bản, số RPM sửa đổi, các bước để xây dựng, cài đặt, và dọn dẹp một gói, và một changelog. Nhiều gói có thể được xây dựng từ một file RPM đặc tả duy nhất, nếu muốn. Gói RPM được tạo ra từ các tập tin RPM đặc tả bằng cách sử dụng công cụ rpmbuild.

File Spec thường phân bố trong các tập tin SRPM, có chứa các file spec đóng gói cùng với mã nguồn.

Một RPM điển hình là phần mềm tiền biên dịch sẵn sàng để cài đặt trực tiếp. Các mã nguồn tương ứng cũng có thể được phân phối. Điều này được thực hiện trong một SRPM, bao gồm cả các file "SPEC" mô tả các phần mềm và cách nó được xây dựng. Các SRPM cũng cho phép người sử dụng để biên dịch, và có thể sửa đổi, mã chính nó.

Một gói phần mềm có thể chỉ chứa các script là kiến trúc độc lập. Trong một trường hợp như vậy chỉ có một SRPM có thể có sẵn; đây vẫn là một RPM cài đặt.

Phân nhánh

[sửa | sửa mã nguồn]

Tính đến tháng 6 năm 2010, có hai phiên bản của RPM đang phát triển: một dẫn dắt bởi dự án Fedora và Red Hat, và phiên bản kia bởi một nhóm riêng biệt được dẫn dắt bởi một nhà bảo trì trước của RPM, một cựu nhân viên của Red Hat.

Sửa đổi quan trọng đầu tiên của cộng đồng rpm.org là trong tháng 7/2007; phiên bản 4.8 phát hành tháng 1/2010, phiên bản 4.9 tháng 3/2011, 4.10 trong tháng 5/2012, 4.11 tháng 1/2013, 4.12 tháng 9/2014 và 4.13 tháng 7/2015.

Phiên bản này được dùng trên các bản phân phối như Fedora, Red Hat Enterprise Linux, openSUSE và SUSE Linux Enterprise, Unity Linux, Mageia,[13] Mandriva trước đây (trước 2010).

Jeff Johnson, người bảo trì RPM từ năm 1999, tiếp tục nỗ lực phát triển cùng với sự tham gia của một số bản phân phối khác. RPM phiên bản 5 được phát hành tháng 5 năm 2007.

Phiên bản này được sử dụng bởi các bản phân phối như Wind River Linux, Rosa Linux, và OpenMandriva Lx (Mandriva Linux trước đây đã chuyển sang rpm5 năm 2011[14]) và cũng được dự án OpenPKG cung cấp các gói và công cụ cho các nền tảng UNIX khác. OpenMandriva Lx xem là chuyển trở lại rpm.org[15] trước khi folding.

Chú thích

[sửa | sửa mã nguồn]
  1. ^ a b “RPM Project Roadmap”. rpm5.org. Truy cập ngày 11 tháng 12 năm 2011.
  2. ^ Bailey, Edward C. (2000). “Chapter 1: An Introduction to Package Management”. Maximum RPM: Taking the Red Hat Package Manager to the Limit. Red Hat, Inc. tr. 22–25. ISBN 978-1888172782. Bản gốc lưu trữ ngày 15 tháng 1 năm 2013. Truy cập ngày 13 tháng 8 năm 2013.
  3. ^ Bailey, Edward C. (2000). “Appendix A: Format of the RPM File”. Maximum RPM: Taking the Red Hat Package Manager to the Limit. Red Hat, Inc. tr. 325–336. ISBN 978-1888172782. Bản gốc lưu trữ ngày 21 tháng 4 năm 2016. Truy cập ngày 22 tháng 11 năm 2010.
  4. ^ “RPM Guide-RPM - Design Goals”. Bản gốc lưu trữ ngày 21 tháng 3 năm 2014. Truy cập ngày 14 tháng 4 năm 2014.
  5. ^ “BOGUS Announce”. Truy cập ngày 14 tháng 4 năm 2014.
  6. ^ “RPM Fusion”. rpmfusion.org. Truy cập ngày 22 tháng 11 năm 2010.
  7. ^ “An Analysis of RPM Validation Drift” (PDF). USENIX Association. Truy cập ngày 15 tháng 3 năm 2011.
  8. ^ “Zypper - MeeGo wiki”. Bản gốc lưu trữ ngày 25 tháng 9 năm 2013. Truy cập ngày 14 tháng 4 năm 2014.
  9. ^ “FAQs: About the Projects”. Ark Linux Official Site. Bản gốc lưu trữ ngày 11 tháng 2 năm 2012. Truy cập ngày 14 tháng 4 năm 2014.
  10. ^ “Repair an RPM database safely”. Bản gốc lưu trữ ngày 13 tháng 2 năm 2016. Truy cập ngày 11 tháng 11 năm 2011.
  11. ^ “Supplemental Packaging Software”. Fedora Project. Bản gốc lưu trữ ngày 10 tháng 1 năm 2017. Truy cập ngày 11 tháng 11 năm 2011.
  12. ^ “Add lzip support”. Bản gốc lưu trữ ngày 29 tháng 10 năm 2013. Truy cập ngày 24 tháng 10 năm 2013.
  13. ^ “Mageia 3 Release Notes: Package management”. mageia.org. ngày 19 tháng 5 năm 2013. Truy cập ngày 14 tháng 4 năm 2014.
  14. ^ Bodnar, Ladislav & Smith, Jesse (ngày 22 tháng 11 năm 2010). “DistroWatch Weekly”. DistroWatch. Truy cập ngày 22 tháng 11 năm 2010.
  15. ^ “Sailfish Alliance? Also some plans and thoughts of where to go in future direction.”. Bản gốc lưu trữ ngày 19 tháng 8 năm 2016. Truy cập ngày 6 tháng 4 năm 2016.

Liên kết ngoài

[sửa | sửa mã nguồn]
Chúng tôi bán
Bài viết liên quan