Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
RFE: implement a weekly DNF-countme-compatible query #2251
Comments
|
This issue was moved to
|
|
I'm looking at the DNF Count Me feature and wondering: If we are running on a Unfortunately, I don't think so, and we do not run regular I'm currently looking at creating a |
|
Moreover, updates usually only happen once every two weeks for Fedora CoreOS for example thus we would not report every week. |
You're correct. A really nice/fundamental feature of the design is that if you don't package layer, it's basically pure OSTree (this also has an unexpected downside: #1696). Having it be a separate command makes sense to me. In the pure OSTree case, it'd be nice if it were just a single |
|
The current logic implemented in DNF is private (Repo-private.hpp, Repo.cpp) and called only when repos are updated (dnf-repo.cpp) which is not ideal if we want to only make this a single I'm currently working on a standalone implementation in Rust based on the C++ logic in DNF. |
|
From an out-of-band chat: this relies on re-implementing a bunch of libdnf logic, including config parsing. That assumes that config parsers (esp. INI ones) are equivalent, which is rarely the case. A cleaner approach would be exposing an interface to perform the HEAD (or at least to extract metalink/countme details) from libdnf and consuming it here. |
|
Or perhaps even simpler, add support to just fetch the metalink but do nothing with it to libdnf. |
I added a note at coreos/fedora-coreos-tracker#86 but figured I'd make a pointer here too. We now have a feature in DNF where systems ask to be counted once per week, with some very basic data (underlying Fedora OS version, OS variant ("coreos"), architecture, and an age bucket). This is documented in
dnf.conf:I know this isn't an exact match with what you're looking for, but having data in a way that is an exact match would be very helpful for me. We already have the DNF code in place in F32, and the first-pass backend is in progress. (Right now, we're getting information extracted from the logs, so we have a delay, but it's great for monthly reports, etc.. Future implementation may get info directly from the proxies in closer to real time.)