I wasn't offering a counter point, rather saying that things could be much simpler and use existing infrastructure, no need to "reinvent the wheel" or "recreate the black thread", and that at some point it kinda looks as if you are over convoluting things.
The "installer" the way I see it, should not "live in the repos", rather inside the distro, be intrinsic to the distro with a common interface for the local package management infrastructure, and "self installable pacakges" could be analogous as the ODF files (simply specially crafted .zip files with a distinct extenstion) in that the internal heriarchy and the XML descriptors define the type of file and what it does (and what makes an ods, odp, odt file a spreadsheet, presentation or text file, respectively).
I wouldn't advise starting using those as general packages, though; make it strictly for third party software that wouldn't otherwise deal with native package management policies/hierarchies/licenses/etc.
PackageKit does not replace or enhance the native package system. It's just a veneer over it. Literally, it's just a library and a GUI that abstracts "yum install" and "apt-get install" to "pkcon install", combined with some policies about to make finding dependencies a bit easier. PackageKit knows absolutely nothing about how to unpack packages, resolve dependencies, download updates, or anything. All it does is call out to a yum or apt backend to do all the actual work. PackageKit is entirely and utterly incapable of installing any software that is not already packaged in the system's native package format and likewise incapable of updating any software not in the distro's native repository format.
So there has to be a new format defined, or you have to use one of the existing formats and use something like alien to get them into the native package databases. This is the path LSB tried to take by mandating RPM 3.x as the official package format; unfortunately, they left too much of the rest of the process completely unspecified. Plus RPMs and the like don't support licenses/EULAs which while distasteful are mandatory for most third-party publishers (heck, even a lot of Open Source/Free Software installers use them!).
Given the limitations of the existing formats, I feel it is best to create a new one. I have in the past proposed updates to both dpkg and rpm for more application-oriented installers and they have been roundly rejected because the developers think their locked-down package silos are a Freedom-saving feature rather than a user-hostile design flaw.
Which means the installer is a package in the distribution's package repository. All software in the distribution comes from its package repository, including (for example) rpm, PackageKit, yum, and so on. So the installer must be a part of the distribution's repository.The "installer" the way I see it, should not "live in the repos", rather inside the distro, be intrinsic to the distro with a common interface for the local package management infrastructure
What I meant is the same thing you meant: the installer has to be a part of the distribution's native package set that the distribution ships and supports, not something the user must manually install by himself.
It doesn't have to be installed by default. The MIME/extension lookup feature Nautilus/Konquerer/Firefox implement via PackageKit means that the native packaging system can install the installer package on demand the first time the user clicks on an installer file. This is important, because I can guarantee you that the installer will not be in the default install set, because distros like Fedora have very strict policies and a lot of politics involved in deciding what goes into that default install set. Luckily, it doesn't matter. So long as the installer is in Fedora's repository, it'll Just Work if the user ever needs it. Magic!
I have no intention of replacing the core package infrastructure of a distribution. I'm not sure that even makes sense: the way you manage a _platform_ and the way you manage an _application_ are fundamentally different. You can build a single system that does both, but said system will be highly complex. RPM and DPKG for instance are massively complex beasts, and still have a crappy user-experience for handling applications. Fedora/RedHat for instance relies on a whole separate database (comps) for logically grouping the plethora of packages that make up a single application into a user-friendly bundle... and the user still ends up being exposed to a ton of firefox-foobazbigglerarr package names in various bits of the graphics UI.I wouldn't advise starting using those as general packages, though; make it strictly for third party software that wouldn't otherwise deal with native package management policies/hierarchies/licenses/etc.
The way I've specified things is tightly tailored for actual applications (things that run in the GUI, get a menu entry, and of which the user is intended to be acutely aware of), based on how actual application-oriented installers for both Windows and Linux have worked for many years. It looks big and complicated only because it's so different than how RPM and DPKG and such work today, because they're just not designed for application-oriented experiences.
If successful, it might be beneficial to expand beyond pure applications and into frameworks and plugins as well. Those have slightly different user stories than an application, slightly different requirements, but nothing too terribly onerous to add. Better to stay focused at first, though. Frameworks basically need to depend on development tools which can be a bit trickier to rely on ("C Development Environment" is not something you can cleanly define as a platform), and plugins require dependencies on applications/frameworks on potentially very specific versions (.e.g, this plugin works with LibAudioFoo version 1.1.3, because the authors of LibAudioFoo are asshats and break their plugin ABI every point-release; so you end up needing dependent updates or multiple installed versions, which a pure application has absolutely no need for period).
(Suffice to say, after packaging for four distributions over the last 10 years and doing installer maintenance on Windows for almost as long, I've been putting a LOT of thought into this subject over the years. Just haven't had the gumption to do anything about it because all of the distributions have been very, very hostile to the idea of taking away their control over users' software, and I've seen every similar -- if less complete -- attempt over the years go through a ton of work just to rot out in the sun because the distributions wouldn't accept them. More often than not out of the fear that users will install Evil Immoral Proprietary Software... like games.)
1 distro for the avg. user, thats all am going to say.
It's still not uncommon to find software for Windows that doesn't have an installer, but instead comes in a zip file you unpack and then run the exe. This is practically identical to the tarball approach, and novice win users are okay with these apps too. What's your opinion on that?
Like others have pointed out, I also think you're making a big deal out of something not that important. Sure, granny may have a hard time installing third-party software via tarballs, but the average computer user upon stumbling on a problem already knows that typing the problem in google will eventually reveal a solution.
PS: What do you mean by NVN being hard to install? Just the other day (when I found out that there was a linux client... yes, under a rock that's right) I downloaded the resources, client and last patch from the server, uncompressed everything and it was working.