#23 Mark this package as self-destruct
Merged a month ago by ignatenkobrain. Opened a month ago by ignatenkobrain.
rpms/ ignatenkobrain/fedora-obsolete-packages self-destruct  into  master

@@ -13,7 +13,7 @@ 

  Name:       fedora-obsolete-packages

  # Please keep the version equal to the targeted Fedora release

  Version:    32

- Release:    22

+ Release:    23

  Summary:    A package to obsolete retired packages

  

  # This package has no actual content; there is nothing to license.

@@ -820,6 +820,9 @@ 

  %obsolete_ticket https://bugzilla.redhat.com/show_bug.cgi?id=1757792

  %obsolete CGAL 5.0-0

  

+ # This package won't be installed, but will obsolete other packages

+ Provides: libsolv-self-destruct-pkg()

+ 

  %description

  This package exists only to obsolete other packages which need to be removed

  from the distribution for some reason.

@@ -839,6 +842,9 @@ 

  

  

  %changelog

+ * Tue Nov 12 08:16:26 CET 2019 Igor Gnatenko <ignatenkobrain@fedoraproject.org> - 32-23

+ - Mark this package as self-destruct

+ 

  * Thu Nov  7 2019 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> - 32-22

  - Also obsolete other binary packages of zanata-platform

  

With libsolv 0.7.8+, this will make Obsoletes to take an effect, but it
won't actually install this package.
With older libsolv versions, this won't do anything.

References: https://github.com/openSUSE/libsolv/commit/25356d16b4520d716e64c8f9506ef4d00b343c63
Signed-off-by: Igor Gnatenko ignatenkobrain@fedoraproject.org

Funny. What about changing libsolv-self-destruct-pkg() to
libsolv-package-only-apply-deps() or smth that is more self-explanatory?

@zbyszek I think self-destruct is better name since it describes what happens to this package. Because if it satisfies some dependency, it can't "apply deps", since it will be "not installed".

libsolv-remove-at-end-of-transaction() then? But OK, if libsolv developers think that this a good name, then let's not discuss this here.

The patch looks OK. I would prefer to wait until libsolv is released with this, because there isn't any particularly strong reason to avoid install f-o-p, and then we can test it properly.

rebased onto ae9381f

a month ago

I haven't got to test this, but generally, I like the idea.

I'm trying to parse the commit message and patch upstream, but I can't quite manage it. Let me ask a few questions about behavior instead:

  1. If I already have this package installed, does it get uninstalled the next time I update after I've updated to libsolv 0.7.8? (Or in the transaction where I update to 0.7.8)?
  2. What happens when I do dnf update if I have updated to libsolv 0.7.8 but f-o-p does not have this Provides: yet on my local system?
  3. What happens if I update to f-o-p with this Provides before updating to libsolv 0.7.8. Does f-o-p get uninstalled in the transaction where I update to libsolv 0.7.8 or on the next transaction?
  4. What is the behavior if we update to this f-o-p and libsolv 0.7.8 in the same transaction?
  5. What happens if I try to run dnf install f-o-p if I don't have f-o-p currently after I've updated to libsolv 0.7.8?
  6. What happens if I do a full-system dnf update if I don't have f-o-p installed but I do have libsolv 0.7.8 installed?

If I already have this package installed, does it get uninstalled the next time I update after I've updated to libsolv 0.7.8? (Or in the transaction where I update to 0.7.8)?

Yes. Any transaction after you have 0.7.8 installed.

What happens when I do dnf update if I have updated to libsolv 0.7.8 but f-o-p does not have this Provides: yet on my local system?

Does it have it in remote repo? If so, it gets removed from your system.

What happens if I update to f-o-p with this Provides before updating to libsolv 0.7.8. Does f-o-p get uninstalled in the transaction where I update to libsolv 0.7.8 or on the next transaction?

On the next.

What happens if I try to run dnf install f-o-p if I don't have f-o-p currently after I've updated to libsolv 0.7.8?

I did not try, but I believe nothing happens and transaction is empty.

What happens if I do a full-system dnf update if I don't have f-o-p installed but I do have libsolv 0.7.8 installed?

Basically, packages which are obsoleted by f-o-p gets removed, but f-o-p does not get installed.

One thing to consider. This is a neat trick. However, isn't it too confusing for our users? What is actually wrong with having f-o-p installed?

One thing to consider. This is a neat trick. However, isn't it too confusing for our users? What is actually wrong with having f-o-p installed?

It's basically the difference between "opt-in autoremoval" and making the choice for them, if I'm understanding correctly. Right now, I can choose to dnf remove fedora-obsolete packages and manually decide if or when to remove packages.

With this change, that choice is now made by Fedora instead. Unless, of course, there's also a CLI/dnf.conf option to disable the self-destruct?

Why would anyone have this package installed? I understand that we can add option for every possible case in life, but what's the point?

Users do not have choice about Obsoletes, they don't have choice about dependencies which they don't want. Why would they have choice about this useless package which jus Obsoletes bunch of other packages?

I agree that nobody needs this installed. I am just careful about arguably "weird behavior" that might be observed by users.

A very important thing to check:

If we add this and it gets released in Fedora 32 GA and if we later realize we need to revert this in an update, will the updated package be installable?

For the record, I realized I had been confusing things above; the Obsoletes would indeed still take effect regardless of the current state of fedora-obsolete-packages on the local system. The only difference here would be that f-o-p would no longer need to be installed locally.

Sorry for introducing my confusion to the conversation.

@churchyard yes, the package will be installable. As long as it does not have this provide.

I think we can ship this in rawhide and collect bug reports if everything goes terribly wrong.

Let's do it :) :wine_glass:

Pull-Request has been merged by ignatenkobrain

a month ago

I'm good with moving ahead with this. +1