Wandering Thoughts archives


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.)

linux/FedoraNotReadingUpdateinfo written at 23:24:37; Add Comment

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.)

tech/CodeAndOperationalDependencies written at 02:43:01; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.