compose: Support exclude list

[cgwalters]

For Silverblue we want to drop PackageKit but it's tricky to do without breaking "traditional" systems. Today one can add exclude=PackageKit to .repo files but this would require more work in pungi which generates repo files.

Let's add to the treefile:

exclude:
  - PackageKit

And have that be exactly the same syntax/semantics as adding that exclude to every input rpm-md repo.

(Though an open question here is whether we want to support repo-scoped excludes, but eh)

[dustymabe]

at a previous job we used depwhiteout extensively, which was basically a way to say we don't care about this dependency and ignore all requests for it to be installed during our rpm transaction. Is this the same thing?

Also we'd probably need to carry the 'exclude' into the client side so that client side operations don't add it back? So we would need to be able to configure it like we do with install/override/kargs etc..

[kalev]

I'm not sure what depwhiteout is, but "exclude=" is a yum and dnf directive that's supported in both yum/dnf.conf and in .repo files. What it does is it hides any packages that match the exclude from the depsolver so that it doesn't "see" the excluded packages. If we hide something that's hard required then transactions just fail with depsolving errors, but in this case we'd like to hide a soft dep, so the depsolver should be able to solve the transaction even if a soft dep is not available.

As for the client side, I think it should be fine to let someone locally overlay PackageKit if they want to for whatever reason. But sure, if there's a way to carry it to client side maybe that's nice too, but the compose side directive should be enough for now I think.

[dustymabe]

If we hide something that's hard required then transactions just fail with depsolving errors, but in this case we'd like to hide a soft dep, so the depsolver should be able to solve the transaction even if a soft dep is not available.

Yeah - when we were using this in the past there was no such thing as a soft dep. I think the depwhiteout functionality would be useful but is seperate from what you are asking for so will end the discussion there.

[jlebon]

Have you thought about the Conflicts: approach? I'm not sure how feasible it is, but it does seem nicer to encode this at a higher level. It would catch the client side as well.

Another approach: would recommends: false not work for this? Given that we want to keep the host minimal, it'd make sense to flip it on in the Silverblue manifest and only explicitly add back recommended packages that fall out that we really want.

[kalev]

Yep, I think Conflicts: should work as well. walters said on IRC yesterday that this could lead to potentially confusing libsolv errors though.

recommends: false would add another difference to what regular workstation composes do, so not so sure about that.

[jlebon]

recommends: false would add another difference to what regular workstation composes do, so not so sure about that

Silverblue composes are already pretty different from regular workstation composes for the same reason of slimming it down though. See e.g. the comps sync scripts in https://pagure.io/workstation-ostree-config/tree/master and the blacklist at https://pagure.io/workstation-ostree-config/blob/master/f/comps-sync-blacklist.yml.

[jlebon]

(Definitely not against an exclude feature overall though. It sounds useful. But I see it more as a tool when dealing with funky repos where you only want some things, whereas in this case, we're using the same repos that are also available on the client machines).

[cgwalters]

My main worry with going all recommends: false is that someone decides to change a hard dep to a weak one in the GFX/desktop or some other stack and since most people have it enabled it will just go missing.

It will also be confusing if we have recommends on by default for layering but not in the base.

[jlebon]

My main worry with going all recommends: false is that someone decides to change a hard dep to a weak one

Hmm yeah, that's a good point. Probably safer to match the dnf default here so that packagers' decisions to add weak deps (or demote existing hard deps) applies across the board.

Re.

walters said on IRC yesterday that this could lead to potentially confusing libsolv errors though

I played with this quickly and it doesn't seem bad:

$ build_rpm foobar
$ build_rpm barbaz conflicts foobar
$ build_rpm bazboo requires barbaz
$ sudo dnf install --nogpgcheck --repofrompath=myrepo,file://$PWD/yumrepo foobar
$ sudo dnf install --nogpgcheck --repofrompath=myrepo,file://$PWD/yumrepo bazboo
...
Error:
 Problem: problem with installed package foobar-1.0-1.x86_64
  - package barbaz-1.0-1.x86_64 conflicts with foobar provided by foobar-1.0-1.x86_64
  - package bazboo-1.0-1.x86_64 requires barbaz, but none of the providers can be installed
  - conflicting requests

[jlebon]

To me, using conflicts seems appropriate for this since it does genuinely conflict with the RPM-OSTree model (unless we actually add an rpm-ostree backend to it...). The only potential pitfall I see is that it would prevent users from pkglayering things that still bring it in but that offer other features that are relevant to Silverblue. Though not sure how many packages fall in that category.

OK, repoquery shows:

$ sudo dnf repoquery --whatrequires PackageKit
PackageKit-command-not-found-0:1.1.12-2.fc29.x86_64
PackageKit-cron-0:1.1.11-1.fc29.x86_64
PackageKit-cron-0:1.1.12-2.fc29.x86_64
appcenter-0:0.2.9-3.fc29.x86_64
appcenter-0:3.1.1-1.fc29.x86_64
apper-0:1.0.0-3.fc29.x86_64
cockpit-packagekit-0:178-1.fc29.noarch
cockpit-packagekit-0:187-1.fc29.noarch
gnome-packagekit-common-0:3.30.0-1.fc29.x86_64
gnome-software-0:3.30.5-1.fc29.i686
gnome-software-0:3.30.5-1.fc29.x86_64
gnome-software-0:3.30.6-1.fc29.i686
gnome-software-0:3.30.6-1.fc29.x86_64
langpacks-install-0:1.0.0-3.fc29.x86_64
plasma-discover-libs-0:5.13.5-1.fc29.i686
plasma-discover-libs-0:5.13.5-1.fc29.x86_64
plasma-discover-libs-0:5.14.5-1.fc29.i686
plasma-discover-libs-0:5.14.5-1.fc29.x86_64
plasma-pk-updates-0:0.3.2-2.fc29.i686
plasma-pk-updates-0:0.3.2-2.fc29.x86_64

The one thing that jumps out is Plasma Discover, which I guess will have to go through the same process as GNOME Software (which we'd want anyway if we don't want it to be in the base layer of a KDE variant either).

[jlebon]

This was done now in #1980.