On 05/24/2016 02:37 PM, James Hogarth wrote:
> 
> On 24 May 2016 08:20, "Kalev Lember" <kalevlem...@gmail.com
> <mailto:kalevlem...@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.

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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Reply via email to