Qt solibs package
 

Current64 XFCE/Mate: For non-KDE users not doing Qt development the full Qt package is quite an overkill. Might it be an idea to provide an solibs package like we do with e.g. glibc-solibs?
:D

The glibc-solibs package was split off the main glibc package for people who don't need to compile anything and only require runtime libc support.
The Qt package on the other hand, does not have non-essential parts. You'll need all of it if you want to use Qt based applications. In your view, what useless bits could be sacrificed?

Splitting the libs from the package can be a lot of work, because upstream can change something anytime and when it breaks you'll have to fix manually.
Personally, if I had to distribute, I'd split it into; qt5-base, qt5-devtools and qt5-qtwebengine

I build currently 5.9.4 LTS with the tools included, because I sometimes use them, but they're not really a requirement for building other programs.
The qtwebengine directory I just rm -rf before building, because 1. I have zero use for it, and 2. it takes all day to compile.

Not sure about what parts the OP needs, but it should be easy to repack the binaries, without rebuilding from source.

@Alien Bob: Just because I have no use for some components does not mean these are useless -- others certainly will need them.

As I said before I am a non-KDE user not doing Qt development, I just want to run some applications that happen to be built with Qt. Actually this is one and only one application at the moment: your VLC 3.0.0. So I expect the libraries to be the only component that I need.
However, from https://www.linuxquestions.org/quest...t5-4175623541/ I know that I need at least one or more includes ...

I added researching what components I can remove for qt5-base (as elcore called it above) to my todo list.

In hindsight this thread is more about "testing the waters" -- comments and ideas are welcome.
:D

Creating a qt5-solibs package by pruning the full qt5 one turns out to be more involved and less rewarding than I expected:
-- More involved: Because of the rather complex structure on the full package isolating the applicable components is more or less guesswork. E.g. the libraries (/usr/lib64/libQt*) are an obvious requirement, but what about the plugins (/usr/lib64/qt5/plugins/*) -- are these .so's also required?
Also my kernel "make xconfig" requirement brings in one or more includes (/usr/include/qt5/*) and possibly more components.
-- Less rewarding: The libraries are by far the largest component: 70.9 MB out of the total full package tar.gz size of 115.6 MB. And the plugins would add some 8.6 MB. In other words the eventual savings are not worth the trouble ...
Other distributions, such as Fedora and Ubuntu, work around this size dilemma by providing a largish number of packages with only one or a few libraries each. They can do that thanks to their dependencies handling, whereas Slackware cannot.

So no qt5-solibs package by me ...
:D

It took you less than a week to produce good evidence and decide independently about something that Fedora and Debian still haven't learned after twenty years -- that splitting packages is confusing and pointless -- you should feel really good about that :D

No I did not nor did I intend to do so. I just said that Fedora and Ubuntu can keep the installed size down by splitting the package thanks to their dependencies handling, whereas Slackware can only do all-or-nothing.
It should be noted that, though in this particular case their **) results coincide more with what I am looking for, I in general like our ***) approach (no dependency handling, the "database" being ordinary files that can be handled with standard tools) much better -- otherwise I would not have been a Slacker since 3.1 *) ...
:D

*) And a BSD-like init system (no sysvinit, no systemd), configuration via text files and so on!

Edits Feb 26, 2018: to clarify:
**) i.e. Fedora and Ubuntu
***) Slackware

Qt custom package
 

One expects an XXX-solibs package to provide the full runtime. But as I said previously:As an experiment I created a qt5-custom package targeting only my own use case:
-- running vlc 3.0.0
-- kernel: make xconfig
That package turns out to take only 19.0 MB. These savings certainly are worth the trouble!

For the curious:
-- i586: https://drive.google.com/file/d/1vsW...ew?usp=sharing
-- x86_64: https://drive.google.com/file/d/1BsE...ew?usp=sharing
-- build: https://drive.google.com/file/d/1jRF...ew?usp=sharing

All sizes as mentioned are for tar.gz's.

useless nonsense.

this might be enough for vlc, but not for other apps.

I have no idea of which saving you are talking, if you want a complete Qt solib package, you can remote
the help, the cmake files, the development headers
maybe some binary tools like assistan linguist, ..

the rest, all libs and Qml files, might be needed for other applications
since the files you remove are no trouble at all, it is for sure not worth any effort at all

If you have no Qt apps running that needs this, and want just vlc, why not building it statically linked against Qt?
or download an appimage
this would be much simpler

and you can use make gconfig to not have a Qt gui for the kernel.
so why not living without Qt at all, if some files are such a problem for you?

@a4z:
Thank you for your kind response.

That is exactly what I said. Adding the support for another application should not take more than half an hour though.

In the quote in the post you responded to I mentioned a full package tar.gz size of 115.6 MB. I would say that "my" 19.0 MB is some saving.

I use xconfig for its search function, gconfig does not have one.

For those who may be curious, only xconfig and menuconfig support searching. In menuconfig, it uses the same hotkey as searching in manpages... that is using the forward slash '/'. It will then print out the results with numbers you can use as hotlinks to jump to that option.

This one here's 51M and has everything except qtwebengine (webkit).

And BTW there's a nconfig which also supports search, and works without X.

you are welcome


except you need to build Qt, than its a half day + half an hour + some extra gigabyte of space for the build files

or, you have everything already on place, but what do you spare then?


there are distributions that split packages in absurd many sub packages, and than you can install exactly just the needed ones
what you actually request is this, and not a Qt solib package.

and than, why stop with Qt, most boost libraries, except program options, for example, are totally unused.
why not also split this package, and than all others .....

Slackware (and Arch and some others) do not do this, and this is good.



as other mentioned, there are more alternatives that provide your functionality


please note, I do not want to stop you from experimenting around, continue doing so.
I just wanted to give you some feedback and fix the thing that you do not ask for a solib package but for multiple packed packages, with package-dev and so on...

@bassmadrigal: It never occurred to me that menuconfig might have a search feature -- thks for the tip.

@elcore: Until now the fact that I referred to Alien Bob's qt5 package was irrelevant as I expect all "full" qt5 packages to be biggies. Your SBO un/compressed package size is 51/175M, Alien's 74/320M. "Internally" I use tgz values instead of these txz ones -- Alien's then becomes 108/320M and with some detail roundings 115/320M.

@a4z: I must have expressed myself very badly for you to keep thinking that I requested the qt5 package to be split into (potentially) many subpackages. I did and do not.
Also I use Alien's full package as a "treasure trove" to extract the needed components from. So adding e.g. another library does not take more than determining which library (via ldd or otherwise), adding a line to my slackbuild, running the amended slackbuild (which takes less than a minute) and upgradepkg'ing the result. I could do several rounds within that half hour.

:D

I've reduced compressed size by additional 50M, and compile time by additional hour or so.
It's only used for some multimedia and networking stuff, there are no qtweb browsers or kde here. For those few packages that I build, it works ok.
Only tested 5.9.6 (previous ones 5.6 or 5.7 may not be as modular as this)