Seems sane to me but I'm not an expert in the mesa stack.

@mclasen Did you know why its not pulled in as a dependency?

It looks like before it was

$ rpm --dbpath=$(pwd)/rpmdb -q --whatrequires 'mesa-libEGL(x86-64)'
libglvnd-egl-1.0.1-0.1.20180226gitb029c24.fc29.x86_64
libglvnd-gles-1.0.1-0.1.20180226gitb029c24.fc29.x86_64

https://src.fedoraproject.org/rpms/libglvnd/c/8a6c7f93d581a661e78467f32c76fb7ed2e73ef3?branch=master

Yet something confusing here is that rpm-ostree should be installing recommends by default; see https://github.com/projectatomic/rpm-ostree/issues/718

Hmm...looking at the contents in https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180331.n.0/logs/x86_64/AtomicWorkstation/ostree-4/create-ostree-repo.log
it's also missing other Recommends packages like e.g. hardlink.

Doing a compose locally using my f27 dev container targeting rawhide content, I can't reproduce.

I am starting to think this is likely a libsolv change in rawhide (it can't be libdnf since rpm-ostree has a fork currently).

Nope, I updated my rawhide dev container to exactly the pkgset from that compose...and still locally can't reproduce the behavior. I get both hardlink and mesa-libEGL-18.0.0-1.fc29.x86_64 etc.

Something interesting here is note that in the compose AtomicHost does get grubby and hardlink: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180331.n.0/logs/x86_64/AtomicHost/ostree-3/create-ostree-repo.log

My next thought was that somehow this was something like packages conflicting, and libsolv tossing out things that conflicted, but that seems unlikely, and I did test giving the explicit Workstation input repo.

I think my vote here is to merge this PR and see what happens...if it works then we'll keep looking for root causes, if it fails, then the error message should be very useful.

Commit 8200685 fixes this pull-request

@walters as I noted at https://bugzilla.redhat.com/show_bug.cgi?id=1569242 , the obvious difference between FAW and FAH composes is that the base repo for FAH composes is the Everything tree, but the base repo for FAW composes is the Workstation tree. I think that's why this difference happens: rpm-ostree pulls in weak dependencies when they're available at all, but because pungi(? - I think it's pungi) does not pull them into install trees, sometimes they're missing from the Workstation tree and thus the FAW ostree can't include them. As Everything always includes all the packages, they're always available to the FAH compose.

Let's look at the hardlink example in the 20180409.n.0 compose (most recent I can find where the ostrees both succeeded). Here's the FAW log and the FAH log . FAH has hardlink, FAW does not. Now look at the Everything tree's h directory and the Workstation tree's h directory - Everything has hardlink, Workstation does not.

So basically I think this is ultimately pungi's fault - which is what https://bugzilla.redhat.com/show_bug.cgi?id=1569242 is about - and the ostree bits aren't doing anything wrong here.