Provide version comparison function for PkPackage
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 12/100
Hướng nghiên cứu
Start with the PkPackage object and pk_package_get_version(), which the issue says return backend-specific version strings. The proposed pk_package_compare_version() would need a backend hook set when each PkPackage is created, so the apt and dnf backends are the places where the comparison would differ. The issue leaves open whether to add a virtual function or normalise versions, and it has been idle for about 590 days, so a maintainer decision on the design comes first. Done would mean an agreed API plus per-backend comparison.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
tl;dr: Please provide a int pk_package_compare_version (PkPackage *self, const char *other_version) API, which calls a backend-specific version comparison algorithm for that PkPackage.
As I understand it, the version returned by pk_package_get_version() is in a numbering format defined by the backend it comes from, and the format is not documented in the PackageKit documentation (as far as I can tell). So the apt backend will return versions using the Debian versioning scheme while the dnf backend will return versions using the Fedora versioning scheme (or other RPM vendors’ version schemes).
This makes it problematic for PackageKit clients to compare the versions of two PkPackages to try and work out which one is newer. So algorithms like Appstream’s version comparison algorithm were invented, which try and work for all versioning schemes. But they have corner cases and can’t work perfectly. This leads to problems like https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2273.
I think there are two ways to fix this:
- Define a single versioning format which is used by PackageKit, and require PackageKit backends to convert packages’ versions to this format when creating a
PkPackage. I don’t think this is a good idea, because it means the version numbers the user sees might not correspond to what the distro tooling/website/command line clients use. It might also lead to loss of precision depending on how the conversion was implemented. - Provide a version comparison virtual function on
PkPackage, which is provided by the backend when it creates thePkPackage, and can be used by clients to compare the versions of any twoPkPackages from that backend. So the dnf backend would provide a comparison function following the relevant dnf versioning scheme, the apt backend would provide an implementation of Debian version comparison, etc. and the client code doesn’t have to worry about the difference.
I hope I haven’t misunderstood the history or semantics of any of the PackageKit functionality here. I would be very happy to be told I’ve got it all wrong and either (1) or (2) is already implemented.
- Ngôn ngữ chính
- C
- Star
- 360
- Fork
- 196
- Merge trung bình
- 4 ngày 24 phút
- Pull request đã merge (30 ngày)
- 6
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của PackageKit/PackageKit
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
PackageKit/PackageKit#1027 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
PackageKit/PackageKit#1026 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
PackageKit/PackageKit#1000 · 1 bình luận ·
-
bashisms in /etc/profile.dĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
PackageKit/PackageKit#705 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
PackageKit/PackageKit#668 ·
Tất cả issue của PackageKit/PackageKit
Issue tương tự
-
native-cpu: -Wreturn-type in skainet_row_threads.c:150 (worker fn has no return)Có thể đã có người làm @Doomguy-BFG9000 đã nhận hôm nay. Đang mởgood first issue size:xs skill:native
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
SKaiNET-developers/SKaiNET#1358 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
I/O internal correctness medium priority rt_lib
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
libsdl-org/SDL#16539 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
git-workflow task-4
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày