Re: Icon size in Okular and other applications
- Date: Sun, 19 Mar 2017 09:08:23 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: Icon size in Okular and other applications
solitone posted on Sun, 19 Mar 2017 08:17:39 +0100 as excerpted:
> Just a curiosity. In debian it seems I don't have any indication on
> slots, so it's not immediate to know whether a package is based on
> kde4 or framework5. For instance:
> solitone@alan:~$ apt-cache policy okular
> Installed: 4:16.08.2-1+b1
> Candidate: 4:16.08.2-1+b1
> solitone@alan:~$ apt-cache policy kde-baseapps-bin
> Installed: 4:16.08.3-1
> Candidate: 4:16.08.3-1
> kde-baseapps-bin is the debian package providing kdialog.
> Is there a quick and easy way to find out whether an application is
> based on kde4 or framework5, apart from looking at the version details
> in every application?
FWIW, slots are gentoo's package-management mechanism for allowing
multiple versions of something to be installed at the same time, assuming
of course that they don't actually install any files to exactly the same
path. Most commonly slots are used for libraries where the filenames
don't collide because they're say *.so.1.2.3 and *.so.2.3.4, but they are
often used for things like desktop major versions as well, to make
tracking what's installed easier even when installing all packages of
both slots isn't actually supported, and that's what you see here.
Slots default to 0 if unset, and that's what most packages that haven't
been specifically designed to allow more than one version to be installed
at the same time use.
So it's not surprising that Debian doesn't have an exactly similar
mechanism because slots, as seen here, are gentoo-specific.
There should be a way to query dependencies, and they have to be set
correctly no matter the package management system or the package will
have much bigger problems.
I don't know Debian's packaging system well enough to give you an exact
command, but querying it for what it depends on, and then piping that
query to a grep for something like kdelibs, a kde4-only package that any
kde4-based app should depend on, should work. Or grep for the qt
dependency, qt4 or qt5.
Alternatively, a method that doesn't depend on a package-manager query,
but instead on the elf-executable information, run ldd on one of the
binaries. That should produce a list of all the libraries it's linked
against, and again, you can grep that for kdelibs or one of the qt
libraries, and see that way whether it's kdelibs4 or kde-frameworks5
based, or qt4/5 based.
You'll probably have to play around with the command and grep a bit (does
the STDOUT or STDERR need piped to grep? do you want to do a grep -q and
rely only on exit code, or do you prefer to see the actual grepped line,
etc.), but either of these should be reliable enough to script if you
like, once you get it working. Then you'll have your own script to run
and won't have to remember the details. =:^)
Someone here that's more familiar with Debian package management can
probably post a nice one-liner, if you're not comfortable using grep, etc.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman