reducing duplicate information in upgrade output #326
Comments
|
Does that fit in an 80x24 window? I think that's the major constraint we have with this stuff. Otherwise, yeah, looks good to me. |
|
The constraint of 24 rows doesn't make any sense to me, as the output will routinely go over that when there are multiple packages in the transaction. At a constraint of 80 characters wide, even the current output will wrap with long package names. Example: I also tried to trigger this wrapping for a long package version, and I think I found a bug. The current rawhide version of iscsi-initiator-utils is If we're struggling for space to make the output work in 80 characters width, I would suggest dropping the arch field. Users know what architecture they're running, and packages switching to/from noarch is fairly uncommon. Even when it does happen that doesn't necessarily need to be in the default output. It could look something like this: |
|
I am sorry but having additional column is a nice idea if we would have only a table for upgrade operation. For downgrade operation the name of the new column is not the best and for operation remove and install the additional column is inappropriate. In a case when replaced package the scheme will also not work nicely. In case when one package is replacing multiple packages it would be also a problem. Obsolete - package is replacing a package or packages with a different name or with the same name. I would be very careful with dropping ARCH column because even standard x86_64 system uses 3 basic architecture -> x86_64, i686, noarch, but there could be even more compatible architecture names. |
|
x86_64 will potentially have seven architectures now ( |
For a downgrade operation, the old version would just be higher than the new version. Old and new in this context do not mean a version that sorts higher, but rather old as in before the transaction and new as in after the transaction. If you'd rather the names of the columns be literal before/after version instead of old/new version, I would be fine with that as well. Example: For a remove or install operation, it would be simple to use "n/a", "none", or "-" as needed.
I think the "n/a" solution can work for this too. The replacing package would only have a version in the new version column, and the packages being replaced would only have a version in the old version column.
I only brought up the arch column because of the feedback about the terminal size constraints. I still feel that it's not necessary output the vast majority of the time, but I don't have a problem keeping it. Let's drop that idea and just keep this issue focused on the original goal of not having duplicate lines when possible. |
|
It would be really nice if the output was in some way user-configurable. If a user has a small terminal, they probably especially don't want the upgrade operation taking up double vertical space, maybe they might choose to opt out of showing the Arch column if they don't find it useful. |
|
It also hides the moment when packageX Replaces packageY. |
j-mracek
added
the
Triaged
|
dnf5 is now replacing dnf4 (and yum) in this rawhide update I just got, so this feels like a good time to comment. dnf4's output is great, I think: Each package on one line, unless the name is very long or the package is replacing something with a different name. dnf5 is doing this: Which is not only repeating a lot of information, but because the phrase "replacing pipewire-jack-audio-connection-kit-libs" is so long it's using 103 columns per line, and at 80 columns that means there's 4 vertical lines per package update. dnf5 is a big upgrade, I'm happy to install it. This one thing feels like a bit of a step backwards though. |
|
Another possible way to handle this would be to include two version strings in the version column when it is an upgrade. In an install or remove transaction, just a single version can be shown. |
|
@carlwgeorge in #1191 there is already a working implementation that use this approach. Take a look there. |
|
To me the biggest problem with the current dnf5 upgrade output (as of 5.2.7) is that the kind of anomalies that you'd want to spop get drowned in the noise when all that info is provided for every single "perfectly normal" update. Including but not limited to obsoletes, which is the thing I think about when I see "replacing". There seem to be some color encoding to differentiate obsoletes from regular updates but it should really say so instead, because color info gets easily lost. |
I noticed in the output of
dnf5 upgradethere is quite a bit of duplicated information as compared to the output ofdnf upgrade.Having two lines for every package with (usually) duplicated information is a lot of visual noise. For updates with many packages it makes it difficult to parse the given information quickly. While I understand that each of these fields can technically have a different value, most of this information is usually the same and not that useful to always show.
My first instinct is can we make the default dnf5 output more terse, closer to the dnf output, with just information about the new package? The more detailed output (the "replacing" line) could be available with the verbose flag. For obsoletes we could always show the "replacing" line, which is similar to what dnf does today.
That said, I do like the idea of always seeing both old and new versions in the output, but that is the only field I feel that way about. Perhaps we could change the output to be something like this:
This will show the most important changing information (the version) while leaving out the information that is usually the same. What do you think?
The text was updated successfully, but these errors were encountered: