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
Created attachment 1144311 [details] Split GIO from glib (#1266118) Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=13576582
Created attachment 1144993 [details] Revised patch
Instead of splitting up the package, we could just weaken the Requires to a Suggests.
(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%.
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.
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.
(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...
(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.
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?
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.
(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: ?
Which is the stronger one, Recommends or Suggests ? I think we want the one that does install by default.
(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
Thank you. I can uninstall shared-mime-info now.