Fedora Project Leader Envisions The Project Becoming An "Operating System Factory"

[mroche]

openSUSE which uses RPMs handles this just fine by adding the concept of vendors into it's package manager, which makes it the only sane binary distribution to deal with conflicting packages in external repos.

That's actually very interesting and a unique feature, I did not know of this[0]. Thanks for pointing it out! Going through Red Hat's Bugzilla to see if anyone's brought it up before, and if not, I'll put that request in.

For me, a bit thing that keeps me with yum/dnf is history. Being able to view, track, and operate on rpm package history is a really sweet deal when administrating a system. To my knowledge, zypper doesn't have this functionality, but I'm open to being wrong on that.

[0] https://en.opensuse.org/SDB:Vendor_change_update

Cheers,
Mike

[andyprough]

Well, that's interesting.

It's always seemed like Fedora was kind of desktop user agnostic. They didn't specifically try to discourage desktop use, but their default installations along with their complex, and poor and conflicting, documentation certainly made desktop installation much more challenging than it needed to be. They also had surprisingly poor hardware and package support compared to Debian and Arch derivative distros.

It's been around 3 or 4 years since I last tried it though, so I'll check to see if anything's really changed. And if it has I'll give it a spin in a VM and check it out again.

I agree, and I doubt that anything has really changed. This press release is probably just more of the same old "lipstick on a pig".

[andyprough]

For me, a bit thing that keeps me with yum/dnf is history. Being able to view, track, and operate on rpm package history is a really sweet deal when administrating a system. To my knowledge, zypper doesn't have this functionality, but I'm open to being wrong on that.

Cheers,
Mike

/var/log/zypp/history

-- Installation history log.

~/.zypper_history

-- Command history for the zypper shell

[elatllat]

Just focus on doing one thing well Fedora.

[mroche]

/var/log/zypp/history

-- Installation history log.

~/.zypper_history
-- Command history for the zypper shell

Searching through a text file that just dumps a single line of data in the order packages are operated on with warning/error comments does not provide the same context, experience, or functionality that yum/dnf history does. Apologies in advance for the longer post:

From the man pages (with examples):

dnf history --help
COMMAND               Available commands: list (default), info, redo, undo,
                        rollback, userinstalled
  TRANSACTION           Transaction ID (<number>, 'last' or 'last-<number>'
                        for one transaction, <transaction-id>..<transaction-
                        id> for range)

* List: Each <spec> can be either a <transaction-spec>, which specifies a transaction directly, or a <transaction-spec>..<transaction-spec>, which specifies a range of transactions, or a <pack‐age-name-spec>, which specifies a transaction by a package which it manipulated. When no transaction is specified, list all known transactions.

# dnf history[list] [<spec>...]
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     7 | history undo 6           | 2020-01-07 02:20 | Install        |   14  
     6 | erase gcc                | 2020-01-07 02:19 | Removed        |   14 EE
     5 | install dnf-utils -y     | 2020-01-07 02:16 | Install        |    6  
     4 | -y upgrade               | 2020-01-07 02:14 | I, U           |  158 EE
     3 | install man-db -y        | 2020-01-07 02:12 | Install        |    4  
     2 | install gcc -y           | 2020-01-07 00:44 | Install        |   14  
     1 |                          | 2019-10-28 05:47 | Install        |  159 EE

* Redo: Repeat the specified transaction... If it is not possible to redo some transactions due to the current state of RPMDB, it will not redo any transaction.

# dnf history redo <transaction-spec>|<package-name-spec>

* Undo: Perform the opposite operation to all operations performed in the specified transaction... If it is not possible to undo some transactions due to the current state of RPMDB, it will not undo any transaction.

# dnf history undo <transaction-spec>|<package-name-spec>

* Rollback: Undo all transactions performed after the specified transaction... If it is not possible to undo some transactions due to the current state of RPMDB, it will not undo any transaction.

# dnf history rollback <transaction-spec>|<package-name-spec>

* Info: Describe the given transactions. The meaning of <spec> is the same as in the History List Command. When no transaction is specified, describe what happened during the latest transaction.

# dnf history info [<spec>...]
# dnf history info 3
Transaction ID : 3
Begin time     : Tue Jan  7 02:12:53 2020
Begin rpmdb    : 173:708c7f663ac5444fa425af80e5972e5e8caca5b8
End time       : Tue Jan  7 02:12:53 2020 (0 seconds)
End rpmdb      : 177:05cb15828a9da43a9e7d15c01aeb60327ddb19c2
User           : root <root>
Return-Code    : Success
Releasever     : 31
Command Line   : install man-db -y
Packages Altered:
    Install groff-base-1.22.3-20.fc31.x86_64 @fedora
    Install less-551-2.fc31.x86_64           @fedora
    Install libpipeline-1.5.1-3.fc31.x86_64  @fedora
    Install man-db-2.8.4-5.fc31.x86_64       @fedora

* Userinstalled: Show all installonly packages, packages installed outside of DNF and packages not installed as dependency. I.e. it lists packages that will stay on the system when Auto Remove Command or Remove Command along with clean_requirements_on_remove configuration option set to True is executed. Note the same results can be accomplished with dnf repoquery --userinstalled, and the repoquery command is more powerful in formatting of the output.

# dnf history userinstalled
Packages installed by user
bash-5.0.11-1.fc31.x86_64
coreutils-8.31-6.fc31.x86_64
dnf-4.2.17-1.fc31.noarch
dnf-utils-4.0.12-1.fc31.noarch
fedora-release-container-31-2.noarch
fedora-repos-31-1.noarch
glibc-minimal-langpack-2.30-8.fc31.x86_64
libxcrypt-4.4.10-2.fc31.x86_64
man-db-2.8.4-5.fc31.x86_64
rootfiles-8.1-25.fc31.noarch
rpm-4.15.1-1.fc31.x86_64
shadow-utils-2:4.6-16.fc31.x86_64
sssd-client-2.2.2-3.fc31.x86_64
sudo-1.8.29-1.fc31.x86_64
systemd-243.5-1.fc31.x86_64
tar-2:1.32-2.fc31.x86_64
util-linux-2.34-4.fc31.x86_64
vim-minimal-2:8.2.076-1.fc31.x86_64
yum-4.2.17-1.fc31.noarch

Lastly, if you supply history with just a package name, it will return which transactions it was a member of:

# dnf history gcc
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     7 | history undo 6           | 2020-01-07 02:20 | Install        |   14  
     6 | erase gcc                | 2020-01-07 02:19 | Removed        |   14 E<
     2 | install gcc -y           | 2020-01-07 00:44 | Install        |   14 >

In my tests in a Tumbleweed container I wasn't getting an ~/.zypper_history file, but again parsing text files is not the same functionality as history in the context of yum and dnf. Different ways to skin a cat, but I'll take the one requiring less effort, provides more context, and works with me rather than making me parse text files.

Cheers,
Mike

[Neuro-Chef]

I havent touched Fedora or any of its derivatives in years.... the RPM package format left such a horrible taste. I lost many evenings an nights of sleep recovering from RPM hell... so has that changed?

I find the Ubuntu apt / *.deb system is very stable and moderately hard to break (it can be broken... but in my experiences DEB hell is harder to get to than RPM hell...)

Funny, I made exactly the opposite experience. I didn't try Fedora before 2016, because I heard it was more difficult to use for Linux beginners (which isn't true IMHO -> having to copy four commands to the command line twice a year for Fedora release upgrades is not a problem, when those upgrades actually just work. And adding RPMfusion once is moch more user friendly than adding dozens of PPAs to get current software versions).
In the years before that I experienced multiple selfdestructing Ubuntu and Mint installations, killed by simple updates that were, for me, impossible to recover. And more recently, even freshly installed Debian VMs would often run into weird dpkg locking issues, thus needing more update restarts than Windows..
So, i prefer rpm over deb.

[andyprough]

Searching through a text file.............

Next time you don't need to write an entire book-length response. I don't currently use opensuse, was simply trying to be helpful based on my past experience. I don't know what you mean by a Tumbleweed container, that sounds like it could be one of many things. But it does not sound like it was a fully functioning system.

[King InuYasha]

That's actually very interesting and a unique feature, I did not know of this[0]. Thanks for pointing it out! Going through Red Hat's Bugzilla to see if anyone's brought it up before, and if not, I'll put that request in.

For me, a bit thing that keeps me with yum/dnf is history. Being able to view, track, and operate on rpm package history is a really sweet deal when administrating a system. To my knowledge, zypper doesn't have this functionality, but I'm open to being wrong on that.

[0] https://en.opensuse.org/SDB:Vendor_change_update

Cheers,
Mike

I haven't seen the feature requested, based on the search in RHBZ. It would be very nice to have "sticky" vendors in DNF, combined with the actionable history feature DNF already has.

[240Hz]

Yes, Fedora KDE. It's been my daily driver for a few years now

Fedora KDE is one of the most bloated KDE distros around, so many useless crap preinstalled . What are they thinking?

[mroche]

Next time you don't need to write an entire book-length response. I don't currently use opensuse, was simply trying to be helpful based on my past experience. I don't know what you mean by a Tumbleweed container, that sounds like it could be one of many things. But it does not sound like it was a fully functioning system.

Running in a rootless podman container (podman run -it docker.io/opensuse/tumbleweed:latest). Other utilities like bash, zsh, python, etc generate ~/.<> files just fine, so must be a zypper related thing in a container context.

When your response is just a log file and history file with no other information, it makes it seem like you view that as an feature-comparable alternative to my original statement, not a suggestion of something to look into. My post wasn't strictly only for you (despite the quote), dnf/yum history doesn't seem to be a well known thing when talking with people who haven't been using it or aren't part of the ecosystem (as others in the thread appear to be) so when package managers come up in discussion and the tooling is mention, I don't think it's a terrible thing to save someone a few seconds and clicks by providing the information in-discussion. But to each their own.

I haven't seen the feature requested, based on the search in RHBZ. It would be very nice to have "sticky" vendors in DNF, combined with the actionable history feature DNF already has.

I created the following feature request. It'll probably get moved to under Fedora, but I put it in RHEL initially so the RHEL devs are aware it would be useful having it in the currently available options.

https://bugzilla.redhat.com/show_bug.cgi?id=1788371

Cheers,
Mike