On 24 May 2016 08:20, "Kalev Lember" <kalevlember@gmail.com> wrote:
>
> On 05/23/2016 10:12 PM, Gerald B. Cox wrote:
> > I opened a ticket on this:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1338198
> >
> >
> > and I have sent a message to klember who just put out the new release
> > on koji yesterday with the same issue.
> >
> > I don't know how long it has been like this, but if someone is unfortunate
> > to uninstall without catching that it is also going to uninstall
> > sqlite-libs (like I was)
> > they are going to have a mess on their hands.
> >
> > Can somebody please intervene and get this fixed?
>
> I don't think this is in any way a corebird packaging bug. It sounds
> like something that uses sqlite libraries is just missing a dependency
> on them, which makes DNF legitimately remove the sqlite-libs package
> when it knows that there are no more users left.
>
> Might be a case of multilib dependencies mixup, where a package that
> needs x86_64 sqlite-libs only has a dependency on "sqlite-libs" and not
> on "sqlite-libs(x86-64)", which makes DNF keep the 32 bit version and
> get rid of the 64 bit. Or something like that :)
>

No you're missing a key bit of the linked bug.

It doesn't just affect packages directly installed by packagekit but any updates too. Before the libhif update they were all marked as dependencies.

So sqlite gets marked as an install as part of the initial system install. Packagekit at some point updated it overwriting that saying it's a dependency. Then dnf autoremove cleans up that at the next opportunity as it now appears a leaf/orphan.

The fixed libhif means from that point on the flag is set right, but the update didn't do anything in retrospect.