corebird incorrectly removes sqlite-libs when uninstalling

[Gerald B. Cox]

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?

[Kevin Fenzi]

On Mon, 23 May 2016 13:12:46 -0700
"Gerald B. Cox" <gbcox(a)bzb.us&gt; 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? 
This looks like it might be another case of
https://bugzilla.redhat.com/show_bug.cgi?id=1259865

ie, you installed sqlite via PackageKit and it didn't mark it as user
installed so when dnf ran it autoremoved it. 

You may be able to check your logs and see when and why sqlite was
installed and if you have the fixed libhif. 

kevin

[Gerald B. Cox]

On Mon, May 23, 2016 at 5:39 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  This looks like it might be another case of
>  https://bugzilla.redhat.com/show_bug.cgi?id=1259865
>
>
>
>  ie, you installed sqlite via PackageKit and it didn't mark it as user
>  installed so when dnf ran it autoremoved it.
>
>  You may be able to check your logs and see when and why sqlite was
>  installed and if you have the fixed libhif.
>  
Thanks Kevin... looks that way... I did have the fixed libhif on my
system.  To correct I did a dnf reinstall sqlite-libs and that fixed it.  I
still need to
go back and research when and why sqlite was installed.

[Gerald B. Cox]

On Mon, May 23, 2016 at 5:39 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  You may be able to check your logs and see when and why sqlite was
>  installed and if you have the fixed libhif.
>  
Well, I am completely confused by this and not sure what needs to be done
other than "be careful" going forward.
There was a comment in the bug report:

I agree, we should figure out what we can advise to users already
affected by this, because this is not going to fix the userinstalled
flags retroactively. So even if they update to latest libhif, dnf
still might autoremove half of their system at any point in the
future.

It appears this bug left a mess and no one is quite sure how to clean
it up.  I ran dnf autoremove on two systems which both are running
kde, and the list generated was different on both systems - even
though
the packages on the list are installed on both systems.

I've been blissfully ignorant of this, and got tripped up by
installing and removing corebird of all things after I had the libhif
fix applied.  So while that may be the solution going forward, it
doesn't appear
to address the ticking timebomb.

[Samuel Sieb]

On 05/23/2016 05:39 PM, Kevin Fenzi wrote:
>  This looks like it might be another case of
>  https://bugzilla.redhat.com/show_bug.cgi?id=1259865
>
>  ie, you installed sqlite via PackageKit and it didn't mark it as user
>  installed so when dnf ran it autoremoved it.
>
>  You may be able to check your logs and see when and why sqlite was
>  installed and if you have the fixed libhif.
>  
That doesn't make sense though.  That bug is just about dnf removing 
"unneeded" packages.  The only reason the reporter lost a needed package 
was because something else was claiming to provide that dependency. 
This case is different.  For some reason, dnf is removing a package that 
is required by many other still installed packages.

[Gerald B. Cox]

On Mon, May 23, 2016 at 7:44 PM, Samuel Sieb <samuel(a)sieb.net&gt; wrote:

>  That doesn't make sense though.  That bug is just about dnf
> removing
>  "unneeded" packages.  The only reason the reporter lost a needed package
>  was because something else was claiming to provide that dependency. This
>  case is different.  For some reason, dnf is removing a package that is
>  required by many other still installed packages. 

Samuel, see my previous reply I just sent regarding fallout going forward.
I'm not sure what the heck is going on.  As I previously mentioned, I was
about to "dnf reinstall sqlite-libs" and then when I did a "dnf remove
corebird" it didn't try to also delete sqlite-libs - so I was assuming it
was something to do with the way the package was marked as referenced in
the other bug report.  That said, when I did a "dnf autoremove" command on
two difference systems the list was different - even though the packages
are currently installed on both systems - so something weird is happening.
Also, I do have the libhif fix applied - and have had for several months,
but just encountered this issue.

[Kalev Lember]

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 :)

Hope this helps,
Kalev

[James Hogarth]

On 24 May 2016 08:20, "Kalev Lember" <kalevlember(a)gmail.com&gt; 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.

[Kalev Lember]

On 05/24/2016 02:37 PM, James Hogarth wrote:
>  
>  On 24 May 2016 08:20, "Kalev Lember" <kalevlember(a)gmail.com
>  <mailto:[e-mail]>> 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. 
I think the user/dep issue is orthogonal to the issue at hand. Sure,
marking it as user installed probably masks the bug, but that's not a
proper fix. The core of the issue is that we have a package somewhere
that needs sqlite-libs, but isn't expressing it in their dependencies,
so rpm let's you remove sqlite-libs breaking that other package.

Whether it's "dnf autoremove" or just "rpm -e" that triggers the
removal
doesn't really matter, it's still a dependency problem in the other
package that needs to require sqlite-libs.

Kalev