Library basis of various components - gtk-2/3/4?

Is there somewhere that offers a tabular summary of various components bundled for UbuntuMATE (22.04 LTS in my case), such that it identifies

  • the commonly used name for the tool/component,
  • the library used for the tool/component (gtk-2.0, gtk-3.0 or gtk-4.0), and
  • the package name associated with that tool/component, such that it would be searchable in a Debian repository or via Synaptic in an Ubuntu repository?

If not, has anyone considered whether that "property" should be one of the properties that are tagged and tracked for each package that is made available in a chosen distro's repository?

Can a "sane" distro be built with ONLY packages which are at a designated library version, i.e. gtk-3.0 ?

Is that the case for UbuntuMATE 22.04 LTS ? 24.04 LTS ?

The Gimp Toolkit (GTK) predates the GNOME project, thus it became GTK+ awhile when it was adopted by the new GNOME desktop (Gimp+GNOME Toolkit) before being returned to just being called GTK in time (GNOME dominate the development of it now).

GTK1 (1998-04-13) & GTK2 (2002-03-11) are now deprecated
GTK3 (2011-02-10) is currently in maintenance mode
GTK4 (2020-12-16) is the current and development version.

However programs/apps that use the specific toolkit/libraries won't all be converted/ported all at the same time, especially those maintained or developed by volunteers, thus apps will use a mixture of various toolkits (ie. those that have been updated, those that haven't).

Libraries/toolkits get removed; usually that'll be Ubuntu & Debian at the same time, eg. I'll provide a post to the removal of Qt4 ( Removing Qt 4 from Ubuntu before the 20.04 release - Foundations - Ubuntu Community Hub ) which in time I expect will happen with GTK2, the question is mostly when.

Yes you could build a distro or flavor using only one subset of the repository, for Ubuntu (or flavors) that involves either being careful with what is included on the seed, or just blacklisting what you don't want included (so builds will break if you include, or force to be included something you've blacklisted). That however would limit what packages could be included (ie. far fewer options for users to choose from).

5 Likes

Thank you, @guiverc,

That is very informative and will help me better define my approach to choosing packages.

However, is there an option to specify such "tags" to be flagged by package management tools to help identify those packages that are "compliant" ?

I use synaptic.

Not that I'm aware of, and whilst I'm not a user of synaptic, I opened it and explored briefly and didn't see a method.

I see synaptic as an end-user tool, where hiding such technical detail is of benefit to most users (hiding the confusing/scary details); though by enabling all fields I feel its easier to pick where version & component versions are shown... but that no doubt is using knowledge I have about the packages (and someone newer to the system may not recognize what I'm seeing)... anyway to confirm requires me to right-click-properties or Alt+Return where I confirm in the deps field. Really I'm just detecting the age and support level of the package(s) rather than any tag you're wanting... ie. gtk-3.0 in your example means a tool that is somewhat outdated by a few years, having not been ported to the newer toolkit (though there could be valid technical reasons for this the developers have yet to address; ie. reasons beyond just lack of developer resources; newer isn't always better for all use cases).

Not that I'm aware of, but I'm not a user of that tool & thus won't be fully aware of what it can do. (I noted it has option settings available for experts only; I didn't explore any of these)

2 Likes

Thank you, @guiverc,

But I was only offering Synaptic as one option. If you know of any way to do what I describe using any of the other package managers, I would very much appreciate your offering me that insight.

I doubt any would... and I'd be no better if you'd asked about my default package manager which is aptitude (I don't usually use package managers)

Package tools would be written for installing packages & managing the dependencies of those packages automatically. You're wanting to search by a specific set of dependency rules which is handled automatically, and is something most end-users aren't interested in.

If I'm looking for a specific package, (eg. photo editor), I usually want all my options to be listed, and I'm happy to explore the depends myself, as that provides clues that will allow me to estimate how it'll run on my machine with the other applications I'm likely to have in RAM at the same time as that matters to me most... I'd not want to search using that criteria though (even if looking for apps to use on an old pentium M device with only 1GB of RAM)

2 Likes

@guiverc,

Well, it may not be the most elegant approach, but here is what I did.

The Script [getPkgInfo.sh]:

#!/bin/bash

dbg=0

packageDetails="/Local/PkgInfo"
packageNameList="/Local/PkgList.txt"
packageScanStat="/Local/PkgList.details"


getPackageList()
{
dpkg-query --list		|
	tail --lines=+6		|
	awk '{ print $2 }'
}


details_long()
{
	dpkg-query --show --showformat='Package: ${Package}
Depends: ${Depends}
Pre-Depends: ${Pre-Depends}
Description: ${Description}
Status: ${Status}
Architecture: ${Architecture}
Bugs: ${Bugs}
Conffiles: ${Conffiles}
Config-Version: ${Config-Version}
Conflicts: ${Conflicts}
Breaks: ${Breaks}
Enhances: ${Enhances}
Essential: ${Essential}
Filename: ${Filename}
Homepage: ${Homepage}
Installed-Size: ${Installed-Size}
MD5sum: ${MD5sum}
MSDOS-Filename: ${MSDOS-Filename}
Maintainer: ${Maintainer}
Origin: ${Origin}
Priority: ${Priority}
Provides: ${Provides}
Recommends: ${Recommends}
Replaces: ${Replaces}
Revision: ${Revision}
Section: ${Section}
Size: ${Size}
Source: ${Source}
Suggests: ${Suggests}
Tag: ${Tag}
Triggers-Awaited: ${Triggers-Awaited}
Triggers-Pending: ${Triggers-Pending}
Version: ${Version}' "${package}"
}


details_short()
{
	dpkg-query --show --showformat='Package: ${Package}
Description: ${Description}
Depends: ${Depends}
Pre-Depends: ${Pre-Depends}
Priority: ${Priority}
Version: ${Version}
Status: ${Status}
Architecture: ${Architecture}' "${package}" |
	awk '{
		pos=index( $0, ":") ;
		beg=substr( $0, 1, pos-1 ) ;
		rem=substr( $0, pos+2 ) ;

		if( rem == "" ){
			printf("%s: %s\n", beg, "NO_ATTRIB_VAL" ) ;
		}else{
			printf("%s\n", $0 ) ;
		} ;
	}' | grep -v 'NO_ATTRIB_VAL'

#Bugs: ${Bugs}
#Conffiles: ${Conffiles}
#Config-Version: ${Config-Version}
#Conflicts: ${Conflicts}
#Breaks: ${Breaks}
#Enhances: ${Enhances}
#Essential: ${Essential}
#Filename: ${Filename}
#Homepage: ${Homepage}
#Installed-Size: ${Installed-Size}
#MD5sum: ${MD5sum}
#MSDOS-Filename: ${MSDOS-Filename}
#Maintainer: ${Maintainer}
#Origin: ${Origin}
#Provides: ${Provides}
#Recommends: ${Recommends}
#Replaces: ${Replaces}
#Revision: ${Revision}
#Section: ${Section}
#Size: ${Size}
#Source: ${Source}
#Suggests: ${Suggests}
#Tag: ${Tag}
#Triggers-Awaited: ${Triggers-Awaited}
#Triggers-Pending: ${Triggers-Pending}
}


if [ -s "${packageNameList}" ]
then
	rm -i  "${packageNameList}"
fi

if [ ! -s "${packageNameList}" ]
then
	getPackageList >"${packageNameList}"
	gvim "${packageNameList}"
fi


#mode=long
mode=short

count=$(wc -l "${packageNameList}" | awk '{ print $1 }' )


if [ ! -f "${packageScanStat}" ]
then
	if [ ${dbg} -eq 1 ]
	then
		head -5  "${packageNameList}"
	else
		tac "${packageNameList}"
	fi |
	while read package
	do
		printf "\t [${count}]  ${package} ...\n"
		details_${mode} >${packageDetails}/${package}.${mode}.txt 2>${packageDetails}/${package}.${mode}.err

		test -s ${packageDetails}/${package}.${mode}.err || rm -f ${packageDetails}/${package}.${mode}.err
		count=$(expr ${count} - 1 )
	done

	touch "${packageScanStat}"

	ls -l ${packageDetails} | more
fi

grep 'gtk-2' ${packageDetails}/*.${mode}* >PkgList.gtk2.txt
grep 'gtk-3' ${packageDetails}/*.${mode}* >PkgList.gtk3.txt
grep 'gtk-4' ${packageDetails}/*.${mode}* >PkgList.gtk4.txt

The output files [typical; one per installed package]:

::::::::::::::
PkgInfo/acpid.short.txt
::::::::::::::
Package: acpid
Description: Advanced Configuration and Power Interface event daemon
 Modern computers support the Advanced Configuration and Power Interface (ACPI)
 to allow intelligent power management on your system and to query battery and
 configuration status.
 .
 ACPID is a completely flexible, totally extensible daemon for delivering
 ACPI events. It listens on netlink interface (or on the deprecated file
 /proc/acpi/event), and when an event occurs, executes programs to handle the
 event. The programs it executes are configured through a set of configuration
 files, which can be dropped into place by packages or by the admin.
Depends: libc6 (>= 2.34), lsb-base (>= 3.2-14), kmod
Pre-Depends: init-system-helpers (>= 1.54~)
Priority: optional
Version: 1:2.0.33-1ubuntu1
Status: install ok installed
Architecture: amd64

The Library Compatibility Scan [one per library; partial]:

/Local/PkgInfo/font-manager.short.txt:Depends: font-manager-common (= 0.8.8-1), font-viewer (= 0.8.8-1), dconf-gsettings
-backend | gsettings-backend, libc6 (>= 2.34), libglib2.0-0 (>= 2.53.2), libgtk-3-0 (>= 3.22), libjson-glib-1.0-0 (>= 1.
5.2), libpango-1.0-0 (>= 1.37.5), libsoup2.4-1 (>= 2.41.90), libsqlite3-0 (>= 3.5.9), libwebkit2gtk-4.0-37 (>= 2.25.1)
/Local/PkgInfo/gir1.2-javascriptcoregtk-4.0:amd64.short.txt:Package: gir1.2-javascriptcoregtk-4.0
/Local/PkgInfo/gir1.2-javascriptcoregtk-4.0:amd64.short.txt:Depends: gir1.2-glib-2.0, libjavascriptcoregtk-4.0-18 (= 2.4
4.2-0ubuntu0.22.04.1)
/Local/PkgInfo/gir1.2-webkit2-4.0:amd64.short.txt:Depends: gir1.2-javascriptcoregtk-4.0 (= 2.44.2-0ubuntu0.22.04.1), lib
webkit2gtk-4.0-37 (= 2.44.2-0ubuntu0.22.04.1), gir1.2-gtk-3.0, gir1.2-soup-2.4
/Local/PkgInfo/gnome-builder.short.txt:Depends: exuberant-ctags, gir1.2-ggit-1.0 (>= 0.28.0.1), gir1.2-glib-2.0 (>= 1.62
.0), gir1.2-gtk-3.0 (>= 3.24), gir1.2-gtksource-4 (>= 4.0.0), gir1.2-jsonrpc-1.0 (>= 3.30.1), gir1.2-peas-1.0 (>= 1.22.0
), gir1.2-webkit2-4.0 (>= 2.26), python3-gi, libvala-dev, clang, gir1.2-dazzle-1.0 (>= 3.37.0), gir1.2-template-1.0 (>= 
3.28.0), gir1.2-vte-2.91 (>= 0.65.0), dconf-gsettings-backend | gsettings-backend, python3:any, libatk1.0-0 (>= 1.12.4),
 libc6 (>= 2.34), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.10.0), libclang1-14 (>= 1:5.0~svn298832-1~), libcmark0.
30.2 (>= 0.30.2), libdazzle-1.0-0 (>= 3.37.0), libdevhelp-3-6 (>= 3.20.0), libenchant-2-2 (>= 2.2.3), libflatpak0 (>= 1.
11.2), libfontconfig1 (>= 2.12.6), libgirepository-1.0-1 (>= 0.9.2), libgit2-1.1 (>= 1.1.0), libgit2-glib-1.0-0 (>= 0.28
.0.1), libgladeui-2-13 (>= 3.22.0), libglib2.0-0 (>= 2.70.0), libgspell-1-2 (>= 1.8.2), libgtk-3-0 (>= 3.24), libgtksour
ceview-4-0 (>= 4.0.0), libhandy-1-0 (>= 1.5.90), libjson-glib-1.0-0 (>= 1.5.2), libjsonrpc-glib-1.0-1 (>= 3.41.0), libpa
ngo-1.0-0 (>= 1.38.0), libpangocairo-1.0-0 (>= 1.38.0), libpangoft2-1.0-0 (>= 1.38.0), libpcre3, libpeas-1.0-0 (>= 1.22.
0), libportal-gtk3-1 (>= 0.5), libportal1 (>= 0.5), libsoup2.4-1 (>= 2.41.90), libsysprof-4 (>= 3.37.90), libsysprof-ui-
4 (>= 3.37.90), libtemplate-glib-1.0-0 (>= 3.28.0), libvte-2.91-0 (>= 0.66.1), libwebkit2gtk-4.0-37 (>= 2.26), libxml2 (
>= 2.9.0)

It isn't elegant, but it's a start! :slight_smile:

Wish there was something better integrated with our package managers of choice. Any takers out there ?

Where I was headed with this was to put a spotlight on packages that are NOT compliant with a library version so as to render visible and raise awareness of where some attention might be needed. :slight_smile:

3 Likes