Tại sao tôi không thể cài đặt nhiều phiên bản của thư viện dùng chung?

Thường có một số trường hợp một chương trình nhất định sẽ phụ thuộc vào phiên bản thư viện xy và một chương trình khác trên xz, nhưng theo tôi biết, không có trình quản lý gói nào cho phép tôi cài đặt cả xy và xz Đôi khi, họ sẽ cho phép cả hai phiên bản chính (như qt4 và qt5, có thể được cài đặt cùng một lúc), nhưng (dường như) không bao giờ là phiên bản nhỏ.

Tại sao lại thế này? Như trong, yếu tố giới hạn ngăn chặn nó là gì? Tôi cho rằng phải có một lý do chính đáng để không cho phép chức năng có vẻ hữu ích này. Ví dụ, không có trường nào cho biết phiên bản nào sẽ tải khi tải đối tượng dùng chung và do đó không có cách nào để Linux biết cách quyết định tải nào? Hoặc thực sự không có lý do cho nó? Giống như tất cả các phiên bản nhỏ được cho là tương thích hay sao?

Trên thực tế, bạn có thể cài đặt nhiều phiên bản của thư viện dùng chung nếu nó được thực hiện đúng cách.

Thư viện dùng chung thường được đặt tên như sau:

lib<name>.so.<api-version>.<minor>

Tiếp theo, có các liên kết tượng trưng đến thư viện dưới các tên sau:

lib<name>.so
lib<name>.so.<api-version>

Khi một nhà phát triển liên kết với thư viện để tạo ra một tệp nhị phân, đó là tên tệp kết thúc trong .sođó trình liên kết tìm thấy. Thực sự có thể chỉ có một trong số chúng được cài đặt tại một thời điểm cho bất kỳ thời điểm nào <name>nhưng điều đó chỉ có nghĩa là nhà phát triển không thể nhắm mục tiêu nhiều phiên bản khác nhau của thư viện cùng một lúc. Với người quản lý gói, .sosymlink này là một phần của -devgói riêng biệt mà chỉ nhà phát triển mới cần cài đặt.

Khi trình liên kết tìm thấy một tệp có tên kết thúc .sovà sử dụng nó, nó sẽ tìm trong thư viện đó một trường có tên là soname . Soname tư vấn cho trình liên kết tên tệp nào được nhúng vào tệp nhị phân kết quả và do đó tên tệp nào sẽ được tìm kiếm trong thời gian chạy. Các soname được cho là được thiết lập lib<name>.so.<api-version>.

Do đó, trong thời gian chạy, trình liên kết động sẽ tìm kiếm lib<name>.so.<api-version>và sử dụng nó.

Ý định là:

• <minor>các bản nâng cấp không thay đổi API của thư viện và khi <minor>được nâng cấp lên phiên bản cao hơn, sẽ an toàn khi để tất cả các nhị phân nâng cấp lên phiên bản mới. Vì các tệp nhị phân đều tìm kiếm thư viện dưới lib<name>.so.<api-version>tên, đây là một liên kết tượng trưng đến bản cài đặt mới nhất lib<name>.so.<api-version>.<minor>, nên chúng được nâng cấp.
• <api-version>nâng cấp thay đổi API của thư viện và không an toàn khi để các ứng dụng nhị phân hiện có sử dụng phiên bản mới. Trong trường hợp <api-version>thay đổi, vì các ứng dụng đó đang tìm tên lib<name>.so.<api-version>nhưng với giá trị khác <api-version>, chúng sẽ không nhận phiên bản mới.

Trình quản lý gói thường không gói nhiều hơn một phiên bản của cùng một thư viện trong cùng một phiên bản phân phối vì toàn bộ phân phối, bao gồm tất cả các nhị phân sử dụng thư viện, thường được biên dịch để sử dụng phiên bản nhất quán của mọi thư viện trước khi phân phối. phát hành. Đảm bảo rằng mọi thứ đều nhất quán và mọi thứ trong phân phối đều tương thích với mọi thứ khác là một phần lớn trong khối lượng công việc cho các nhà phân phối.

Nhưng bạn có thể dễ dàng kết thúc với nhiều phiên bản của thư viện nếu bạn đã nâng cấp hệ thống của mình từ một phiên bản phân phối của bạn sang một phiên bản khác và vẫn có một số gói cũ yêu cầu các phiên bản thư viện cũ hơn. Thí dụ:

• libmysqlclient16 từ một Debian cũ hơn, chứa libmysqlclient.so.16.0.0và symlink libmysqlclient.so.16.
• libmysqlclient18 từ Debian hiện tại, chứa libmysqlclient.so.18.0.0và symlink libmysqlclient.so.18.

Chức năng này không được phép, nó chỉ không phổ biến do kết quả của hầu hết các thư viện đánh số công việc và vì sự bất tiện của việc thay đổi tên gói.

Nếu sử dụng lược đồ số phiên bản rải rác XYZ Phiên bản "micro" Z thường thay đổi trên các lỗi, số "phụ" Y thay đổi theo các thay đổi tương thích ngược và số phiên bản "chính" X phải thay đổi khi thay đổi API (và đôi khi không bật chức năng phụ lớn).

Không bao giờ có lý do mà bạn không muốn sửa các lỗi mới nhất và các thay đổi tương thích ngược cũng không phá vỡ phần mềm của bạn.

Nếu thư viện được phát triển theo cách đó, bạn sẽ luôn có thể thay thế XYZ bằng X. (Y + m). (Z + n). cho bất kỳ m và n đã cho. Tức là bạn phải luôn có thể thay thế thư viện của bạn bằng thư mới nhất trong cùng dãy số chính. Và nếu các nhà phát triển thư viện cẩn thận và số chính tiếp theo tương thích (ví dụ: theo thông báo để loại bỏ mọi thứ, nhưng chưa xóa chúng), bạn thậm chí có thể sử dụng số chính tiếp theo.

Đối với các nhà phát triển gói, điều này có nghĩa là họ có thể sử dụng tên chỉ với một hoặc thậm chí không có tên số để cung cấp cho bạn phiên bản mới nhất chỉ bằng cách cập nhật gói. Nếu họ gửi một thư viện trong một gói abc2thì họ phải trải qua các vòng để di chuyển phần mềm của riêng họ dựa vào abc2để nâng cấp để sử dụng abc3, đôi khi có các gói chuyển tiếp. Sẽ thuận tiện hơn khi bỏ đi số phiên bản chính từ thư viện nếu nó hoạt động với hầu hết các gói phụ thuộc. Vì vậy, ngay cả khi cả hai abc2và abc3nên có sẵn tại một số điểm có sẵn trong một bản phân phối, abc3thường được gọi abc(giống như abc2được gọi khi abc3chưa có) và ngay khi không có gói nào phụ thuộc vào abc2phân phối, nó có thể bị hủyabc2 hoàn toàn.

Lược đồ đánh số không được tuân thủ một cách thống nhất, nhưng tôi chỉ có thể tưởng tượng rằng với sự ra đời của thông tin phổ biến trên internet về cách sử dụng lược đồ đó và áp lực từ người dùng thư viện (bao gồm cả các nhà phát triển phân phối) để làm rõ những điều quan trọng như khả năng tương thích ngược phải đọc qua một tệp THAY ĐỔI có trong thư viện, đã góp phần rằng điều này đã trở nên phổ biến hơn.

Một ví dụ ngược lại, nhưng không phải của một thư viện là intpreter python, không tương thích với các đối tượng được chia sẻ và định dạng tẩy của nó trên một thay đổi số nhỏ. Do đó, bạn sẽ thấy các gói cho python (mới nhất trong loạt 2.7) và python3 (mới nhất trong loạt python3.4) cũng như các gói rõ ràng cho python 2.6 (không phổ biến hơn) cũng như python 3.3.