2020-02-09
I'm likely giving up on trying to read Fedora package update information
Perhaps unlike most people, I apply updates to my Fedora machines
through the command line, first with yum and now with dnf. As
part of that, I have for a long time made a habit of trying to read
the information that Fedora theoretically publishes about every
package update with 'dnf updateinfo info', just in case there was
a surprise lurking in there for some particular package (this has
sometimes exposed issues, such as when I discovered that Fedora
maintains separate package databases for each user).
Sadly, I'm sort of in the process of giving up on doing that.
The overall cause is that it's clear that Fedora does not really
care about this update information being accurate, usable, and
accessible. This relative indifference has led to a number of
specific issues with both the average contents of update information
and to the process of reading it that make the whole experience
both annoying and not very useful. In practice, running 'dnf
updateinfo info' may not tell me about some of the actual updates
that are pending, always dumps out information about updates that
aren't pending for me (sometimes covering ones that have already
been applied, for example for some kernel updates), and part of
the time the update information itself isn't very useful and has
'fill this in' notes and so on. The result is verbose but lacking
in useful information and frustrating to pick through.
The result is that 'dnf updateinfo info' has been getting less
and less readable and less useful for some time. These days I skim
it at best, instead of trying to read it thoroughly, and anyway
there isn't much that I can do if I see something that makes me
wonder. I can get most of the value from just looking at the package
list in 'dnf check-update', and if I really care about update
information for a specific package I see there I'm probably better
off doing 'dnf updateinfo info <package>'. But still, it's a hard
to let go of this; part of me feels that reading update information
is part of being a responsible sysadmin (for my own personal
machines).
Some of these issues are long standing ones. It's pretty clear that
the updateinfo (sub)command is not a high priority in DNF as far
as bug fixes and improvements go, for example. I also suspect that
some of the extra packages I see listed in 'dnf updateinfo info'
are due to DNF modularity
(also), and
I'm seeing updateinfo for (potential) updates from modules that
either I don't have enabled or that 'dnf update' and friends are
silently choosing to not use for whatever reasons. Alternately they
are base updates that are overridden by DNF modules I have enabled;
it's not clear.
(Now that I look at 'dnf module list --enabled', it seems that I
have several modules enabled that are relevant to packages that
updateinfo always natters about. One update that updateinfo talks
about is for a different stream (libgit2 0.28, while I have the
libgit2 0.27 module enabled), but others appear to be for versions
that I should be updating to if things were working properly.
Unfortunately I don't know how to coax DNF to show me what module
streams installed packages come from, or what it's ignoring in the
main Fedora updates repo because it's preferring a module version
instead.)
Code dependencies and operational dependencies
Drew DeVault recently wrote Dependencies and maintainers, which I will summarize as both suggesting that dependencies should be minimized and being a call to become involved in your dependencies. I have various thoughts on this general issue (cf), but perhaps I have an unusual perspective as someone who is primarily a system administrator instead of a developer. As part of that perspective, I think it's useful to think about two sorts of dependencies, what I will call code dependencies and operational dependencies.
Code dependencies are the Python modules, Go packages (or modules these days), Rust crates, C libraries, Node packages, or whatever in your language that you choose to use or that get pulled in as indirect dependencies. You can keep track of at least your direct code dependencies (you're setting them up, after all), and hopefully you can trace through them to find indirect ones. If there are too many indirect dependencies and levels of indirection, this may be a sign (Drew DeVault would likely suggest that you take it as a bad one).
Operational dependencies are everything that you need to operate and even build your program and your system. If you have a web site, for example, your web server is at least an operation dependency. Everyone has an operational dependency on their operating system's kernel, and often on many other operating system components. People using interpreted languages (Ruby, Python, Node, etc) have an operational dependency on the language interpreter; people compiling programs have an operational dependency on GCC, clang/LLVM, the Rust compiler, the Go compiler, and so on. Operational dependencies have internal code dependencies, making you transitively dependent on them too. If you operate a web server that does HTTPS, whether Apache or nginx, it probably has a code dependency on some SSL library, most likely OpenSSL, making OpenSSL an indirect operational dependency for you.
Things can be both code dependencies and operational dependencies, because they're directly used by you and also used by other systems that you need. Some things are so commonly used and so much a part of the 'platform' that you'll likely consider them operational dependencies instead of code dependencies even if they're directly incorporated into your programs; the most significant example of this is your system's C library and, on Unix systems, the runtime dynamic linker.
(System administrators are often quite conscious of operational dependencies because much of our job is managing them. Other people can often assume that they are just there and work.)