Bug 1266118 - Split glib2 package so that non-libgio-2.0.so users don't require shared-mime-info
Split glib2 package so that non-libgio-2.0.so users don't require shared-mime...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
: FutureFeature, Patch
Depends On:
Blocks: base-minimization
  Show dependency treegraph
 
Reported: 2015-09-24 10:07 EDT by Petr Pisar
Modified: 2016-06-02 03:51 EDT (History)
3 users (show)

See Also:
Fixed In Version: glib2-2.49.1-2.fc25
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-01 16:14:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Split GIO from glib (#1266118) (4.28 KB, patch)
2016-04-06 14:47 EDT, Yaakov Selkowitz
no flags Details | Diff
Revised patch (5.21 KB, patch)
2016-04-07 23:53 EDT, Yaakov Selkowitz
no flags Details | Diff

  None (edit)
Description Petr Pisar 2015-09-24 10:07:05 EDT
Current glib2 package run-requires shared-mime-info which is not essential for minimal system in my opinion. Attempt to remove shared-mime-info from system results into DNF abortion because it would remove systemd or dnf. I think the dependency bloat could be cured by moving some file into a separate sub-package.

The shared-mime-info is explicitly run-required by glib2 only because libgio-2.0.so.0 executes update-mime-database that is provided by the shared-mime-info.

Is it possible to split the glib2 binary package in a way that glib2 applications not linked against libgio-2.0.so will not pull the shared-mime-info into the system? For example moving these four libraries into a separate sub-package:

/usr/lib64/libglib-2.0.so.0
/usr/lib64/libglib-2.0.so.0.4400.1
/usr/lib64/libgmodule-2.0.so.0
/usr/lib64/libgmodule-2.0.so.0.4400.1
/usr/lib64/libgobject-2.0.so.0
/usr/lib64/libgobject-2.0.so.0.4400.1
/usr/lib64/libgthread-2.0.so.0
/usr/lib64/libgthread-2.0.so.0.4400.1
Comment 1 Yaakov Selkowitz 2016-04-06 14:47 EDT
Created attachment 1144311 [details]
Split GIO from glib (#1266118)

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=13576582
Comment 2 Yaakov Selkowitz 2016-04-07 23:53 EDT
Created attachment 1144993 [details]
Revised patch
Comment 3 Matthias Clasen 2016-04-08 09:48:40 EDT
Instead of splitting up the package, we could just weaken the Requires to a Suggests.
Comment 4 Yaakov Selkowitz 2016-04-08 10:09:28 EDT
(In reply to Matthias Clasen from comment #3)
> Instead of splitting up the package, we could just weaken the Requires to a
> Suggests.

There's also a question of size, given how much is GIO-specific (GDBus, GApplication, GSettings, etc.); splitting out gio shrinks the glib2 RPM by 26%.
Comment 5 Matthias Clasen 2016-04-08 11:07:32 EDT
Right. But you've just broken every package that has a Requires: glib2 and expects to have glib-compile-schemas available, e.g.

I personally prefer to keep the package unsplit, but lets CC Colin, who's opinion on glib matters to me.
Comment 6 Colin Walters 2016-04-08 11:25:53 EDT
OK, and you're saying because today dnf only links to libglib indirectly via librepo?  The thing is that down the line there's an effort to merge code into https://github.com/rpm-software-management/libhif which does link to libgio.

Though now that libgio is growing lots of desktop stuff I do think it would make sense to move some "core" parts like GCancellable into libglib, but it's complex.

Comment #3 seems simplest if you really don't want shared-mime-info.   The only concern I have around that sort of thing is transaction ordering, but it should basically just work to have update-mime-info to be a %posttrans done once.
Comment 7 Yaakov Selkowitz 2016-04-08 13:25:51 EDT
(In reply to Matthias Clasen from comment #5)
> Right. But you've just broken every package that has a Requires: glib2 and
> expects to have glib-compile-schemas available, e.g.

Besides gsettings-desktop-schemas, what other packages providing schemas would not already require libgio?

(In reply to Colin Walters from comment #6)
> OK, and you're saying because today dnf only links to libglib indirectly via
> librepo?  The thing is that down the line there's an effort to merge code
> into https://github.com/rpm-software-management/libhif which does link to
> libgio.

Curious, what part of libgio?

> Though now that libgio is growing lots of desktop stuff I do think it would
> make sense to move some "core" parts like GCancellable into libglib, but
> it's complex.

Understood, moving things like that is difficult at best.

The thing is, we used to have separate libraries for all these desktop functionalities.  Now that it's all been piled into libgio, it's all or nothing and at the base image level that makes a big difference.

> Comment #3 seems simplest if you really don't want shared-mime-info.   The
> only concern I have around that sort of thing is transaction ordering, but
> it should basically just work to have update-mime-info to be a %posttrans
> done once.

Better than nothing I suppose...
Comment 8 Matthias Clasen 2016-04-11 08:27:58 EDT
(In reply to Yaakov Selkowitz from comment #7)
> (In reply to Matthias Clasen from comment #5)
> > Right. But you've just broken every package that has a Requires: glib2 and
> > expects to have glib-compile-schemas available, e.g.
> 
> Besides gsettings-desktop-schemas, what other packages providing schemas
> would not already require libgio?

I think the burden to collect this information is on you, since you are proposing the split.
Comment 9 Yaakov Selkowitz 2016-05-30 13:33:27 EDT
Given that the shared-mime-info dep could rightfully be weak even if GIO is split out, can we proceed with the former in the meantime?
Comment 10 Matthias Clasen 2016-06-01 09:40:13 EDT
Sure, if you want to push the change to Suggests: and do builds with that, thats fine with me. If you can't give me a patch and I'll do it.
Comment 11 Yaakov Selkowitz 2016-06-01 13:48:41 EDT
(In reply to Matthias Clasen from comment #10)
> Sure, if you want to push the change to Suggests: and do builds with that,
> thats fine with me. 

I can do it, but with Suggests: or Recommends: ?
Comment 12 Matthias Clasen 2016-06-01 14:33:47 EDT
Which is the stronger one, Recommends or Suggests ? I think we want the one that does install by default.
Comment 13 Yaakov Selkowitz 2016-06-01 16:14:12 EDT
(In reply to Matthias Clasen from comment #12)
> Which is the stronger one, Recommends or Suggests ? I think we want the one
> that does install by default.

Then you want Recommends.  Fixed in rawhide with:

http://pkgs.fedoraproject.org/cgit/rpms/glib2.git/commit/?id=87058bd
http://koji.fedoraproject.org/koji/taskinfo?taskID=14340514
Comment 14 Petr Pisar 2016-06-02 03:51:06 EDT
Thank you. I can uninstall shared-mime-info now.

Note You need to log in before you can comment on or make changes to this bug.