Re: Hope this is the right place - recommendations - a one clickinstall package & standardize group "namespace"

[Gabriel Phoenix <gabrieltalks sympatico ca>]

My mindset is not a Linux geek with Internet access but granny who
hardly knows what a program is and where people are still discovering
the telephone alongside a computer.

The ultimate ideal would be one file one-click (or one command) install.
If added to the core functionality the GUIs will quickly adopt it.


> The harder point is "placed all the relevant binaries ... in one directory".
> Given that, an upgrade (to KDE3 in this case) is no harder than
> 	rpm -Uvh *.rpm

This would be handled by a compress bundle which might have a different
file extension (rpb - Redhat package bundle). The result would be
similar to a Java jar file. The manifest would take care of the details.

Oh, add the ability to do individual checks on the whole bundle and
individual packages too.

The scenario: I create xyz game, which needs two libraries. I include
them in a distribution package - presto, the equivalent to a Windows
install program. You download this one file and the packager does its
magic. Now the geek can always look under the hood but granny would ask
"Dependencies? Never heard of them, I just install a program and it
works."

This open up a standard way for commercial distribution.

As for the issue if you should track the bundles like packages, I would
regulate most of that to the frontends, since a bundle would
fundamentally be a collection of packages. I would only maintain a "part
of x bundle" field that could be searched for possible uninstalls. This 
would help solve another problem I see... orphaned packages.


> Only slightly more complicated is installing using a manifest. Assuming
> that "relevant" binaries have been collected, then an install using a
> manifest would look like
> 	ls -1 *.rpm > /tmp/manifest
> 	rpm -Uvh /tmp/manifest
> Manifests become more useful when you realize that URL's are permitted
> in a manifest.

I was thinking of something like a manifest file, you give it
instructions on what, where, and how. An rdf file, perhaps? Then
something like the KDE 3 update would be a simple click. This allows for
a complete install from the net. Imagine one little manifest file
starting the KDE 3 Mandrake upgrade?

Yes, other people are doing it, like Mozilla and Ximain but they are
limited. Think Linux standard method. Also note that Mozilla and Ximain
upgrades do not necessarily work well with the rest of the system.


> I hasten to point out that noone -- including me -- has tried packaging
> "package bundles", you can expect all sorts of problems. I also dunno yet
> whether I'm gonna be able to support the functionality. For production
> deployment, a tracking dependency to test whether the version of rpm
> that used can, in fact, actually install a package bundle", i.e. is concurrent
> access enabled, is absolutely necessary.

What about "requires version #" field? There will be a transition phrase
which will eventually be handled by upgrading. A compressed bundle can
be uncompressed and installed the old way. If net access is required one
could read the manifest to see the location of the needed files.
Technical yes, annoying yes, but not too hard for people who are already
fetching packages. 

The biggest problem I see is when dependencies are not a few files but a
major upgrade (e.g., Gnome 2). More than half of the programs can be
handled by bundling into one program or accessing known good servers.
Then there is the issue of breaking older programs, which I doubt the
packager could ever handle.


> FWIW, Red Hat has standard Group: values, the list is, as always, in
> 	/usr/share/doc/rpm-x.y.z/GROUPS

I checked "Maximum RPM" to see if there was a reference to such
information, either it is not there or I missed it.

> The more general problem, defining consistent Group assignments for the
> entire universe of rpm packaging, is outside rpm's or even Red Hat's scope.

I am imagining if this is the problem now with 1% penetration, imagine
the mess with 5%, 10%, or 25% penetration? 

> I'm not sure that the administrative control's necessary to create
> and maintain a Group <-> package registry can ever be done, or is worth
> the effort at this point, but that shouldn't be taken as a statement
> that I think its a bad idea.

RFC (request for comment) proposal? There is no way you can enforce it
so the only way to succeed is majority rule. Establish a name structure
as *the* accepted standard that programmers can rely on.

Take a look at the menus of on the desktop, Mandrake, Redhat, Gnome, and
KDE. They are all using Group assignment as a guess of what a program
is. The bazaar is great for diversity but they have to at least agree on
the same currency.

I make the argument that the since you are the source of the program you
should have first say on the standard and unless someone can think of a
better way your way should be adopted.

...but that is my opinion.


Once again thank you for your time, Gabriel Phoenix