PolishLinux has an interview with the KPackageKit developers. PackageKit is a abstraction layer over the different Linux package management tools. It is primarily designed to unify the graphical tools and provide a consistent distribution neutral framework for application developers to install add-ons as well. This project was initiated and continues to be maintained by Red Hat developer Richard Hughes who also wrote the initial GNOME frontend to it, called gpk-application. Multiple backends currently exist and it is the default for Fedora and Foresight Linux already. Other distributions including Ubuntu, OpenSUSE, Mandriva, and Gentoo are actively participating in the development of different backends. A KDE interface has been under rapid development recently and just did a 1.0 release last week. This interview provides more details.

How is GTK a "standard" system component? the only standard component of a Linux system is the Linux kernel. You cannot depend on any specific library to always be there. For a system like the one OSX uses, every package that is packaged in that manner has to be built statically against it's dependencies. OSX has a clear base system and third party package division line. Linux does not.

That's up to the distribution, many of which follow the LSB & fd.o standards.

This does neatly highlight one big problem with Linux distributions as a whole though: there is no one to codify or enforce standards of any kind, and there is always someone who thinks they know better and refuse to follow what standards there are.

That's why desktop Linux distros should have a common standard including GTK+ (and Qt, and all that stuff), each version of which should be supported for a reasonably long time (say, 3 years). They need not be based off that standard, just support it. And there should be a distro-neutral package standard for 3rd party software that every distro would understand - again, without the need for the distro to be actually built around it. This could be some kind of binary tarball with additional metadata convertible to the distro's native package system using alien (so that after first install, the same app could then be installed directly from say apt package archives). Of course, the packages should be relocatable, which can be ensured using the binreloc tool from Autopackage.

That's why desktop Linux distros should have a common standard including GTK+ (and Qt, and all that stuff), each version of which should be supported for a reasonably long time (say, 3 years). They need not be based off that standard, just support it.

Fortunately this is exactly what the LSB is about.

Its interface deprecation policy is even longer than three years:
"...interface deprecation policy does provide us with a mechanism for removing interfaces, but only after the interfaces have been marked "deprecated" for at least three major versions, or roughly six years..." http://ldn.linuxfoundation.org/lsb/roadmap

And there should be a distro-neutral package standard for 3rd party software that every distro would understand - again, without the need for the distro to be actually built around it.

Well, probably not on a server system or non-user interface embedded Linux, but most certainly on a desktop linux, because it and Qt are part of the LSB Desktop module and most of the common distributions are actually LSB certified.

OSX has a clear base system and third party package division line. Linux does not.

Well, it does, but it is a lot more convenient to ignore this and continue claiming it doesn't. Otherwise one would need to find new excuses to hide one's personal unwillingness or unability to support Linux as a target platform.