Re: Icon size in Okular and other applications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> okular:
>   Installed: 4:16.08.2-1+b1
>   Candidate: 4:16.08.2-1+b1
> 
> solitone@alan:~$ apt-cache policy kde-baseapps-bin
> 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.

**BUT**...

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




[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux