Announcement: One Click Installer

[Greg K Nicholson]

Krzysztof Lichota:
> Greg K Nicholson napisał(a):
>> The apt protocol ( https://wiki.ubuntu.com/AptFirefoxFileHandler ) will 
>> fix this.
> 
> Yes, this is similar to what I want to achieve, but:
> - it does not provide information for different distributions and other
> systems than APT
> - it does not provide multiple versions for different distribution versions
> - it does not provide localized application descriptions
> 
> And I do not think such amount of information should be put in URLs, it
> is just too big. URLs should not hold data.

For a start, as has been suggested elsewhere, it should be renamed to a 
generic “install” URI scheme, rather than apt. That's just cosmetic.

Perhaps all that other information doesn't need to be included in the 
URL. The installation system could be backed up by a remote library that 
provides all the extra information. (Let's call this the Remote 
Universal Metadata Library idea.) The URL would only have to contain the 
name of the package that should be installed (and perhaps optionally a 
version range).

Once the installation of a particular package/version has been 
initiated, the user's computer would request all the other information 
about that package/version from the remote library, a service running on 
some web server that's known to be trusted. The user's computer would 
have a list of library servers (provided by the distro, like the default 
repositories' addresses are); if one is unavailable it would try 
another. Encryption and so on would be applied as appropriate (and for 
anything else I fail to mention, assume the best solution you can think of).

All library servers would be completely interchangeable as far as the 
user's computer is concerned. Either they would all be mirrors of each 
other and offer exactly the same information, applicable to all distros 
(and not necessarily restricted to Linux); or each server would hold a 
subset, and would (somehow) be able to redirect the user's computer to 
whichever server holds the appropriate subset for any case.

I imagine that the major Linux vendors would each host a library server, 
SourceForge might have one too, as would some or all of the servers that 
currently provide mirrors for open source projects' downloads. Remember, 
we're only dealing with short snippets of metadata, not the installers 
themselves, so this isn't a universal repository of all software — just 
a universal repository of all software installation metadata (ideally).

I assume something like Bazaar (with which I'm only cursorily familiar) 
could make it possible for all the servers to talk to each other 
peer-to-peer-style, so that even tiny distro makers can share their 
metadata with the big guys. And there'd be some magical system to ensure 
that no single library server gets pummelled harder than it has to — 
Mozilla's Bouncer tool might be in the right area.

The user's computer would send to the library server the name (and 
version range) of the package to be installed, plus all the relevant 
details of the user's computer, presumably as a user agent string. The 
relevant details are probably (at least) distro, distro version, 
hardware architecture, user language/locale(s) and preferred 
installation method(s)—apt, rpm, source, whatever.

The library server would know what the current version of the package is 
for that distro/version/architecture/language/install-method 
combination, what repositories and gpg keys need to be added (if 
applicable) and so on. If a package goes by different names in different 
distros, the library would know which names are equivalent and offer the 
right one for the user's distro. For distros that don't use a packaging 
system (such as those from Redmond and Cupertino), the library should be 
able to return the URL of an appropriate webpage or (distinctly) an 
installer.

I'm visualising this library as a vast table with program versions down 
the left, and distro/version/etc combinations across the top. At the 
intersections are instructions like:

<package repo="http://bar.example.com">foo</package>

Sometimes there are several instructions:

<package repo="http://bar.example.com">foo</package> 
<gpgkey>http://baz.example.org/gpgkey</gpgkey>

For Windows (and similarly for OS X) the instructions might be:

<choose> <option> <webpage>http://quux.example.net</webpage> </option> 
<option> <installer>http://quux.example.net/monkeys.exe</installer> 
</option> </choose>

(That's choice for the user's computer; it needn't necessarily be shown 
to the user every time.) Gentoo might use:

<source>http://cheese.example.org/src.tar.gz</source>

(or however Gentoo works.)

The library server would send back — possibly in a simple XML dialect, 
as above — all the information the user's computer needs to be able to 
install the software with no help from the user, although the user would 
probably be shown what was about to happen and would have to confirm the 
installation. Of course, the UI implementation would be up to each distro.

So, given the name of a piece of software you want to install, and the 
details of the computer you want to install it on, this service would be 
able to respond with machine-readable instructions for how to install 
that software on that computer.

(I assume that Ubuntu's packaging infrastructure (at the developers' 
end) is clever enough to be able to populate such a database without 
absurd levels of human input.)