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

[Jeff Johnson <jbj redhat com>]

On Sun, Jul 14, 2002 at 03:17:43PM -0400, Gabriel Phoenix wrote:
> On Sat, 2002-07-13 at 19:43, Gabriel wrote:
> > I presume the developers are reading this and these two recommendations
> > are directed mostly towards them.
> > 
> > Now if I have overlooked something simple, my apologies.
> > 
> > 
> > 
> > The first idea... basically a compressed packages of packages - a
> > "one-click" install package.
> > 
> > The problem: I have lost count of the number of dependencies I have had
> > to fulfill. You need a great deal of patience to try an install and have
> > a dependency of a dependency of a dependency. A newbie and the general
> > user would never have the patience to do this.
> > 
> > The solution: allow for a compressed package of rpm packages and some
> > extra support (through scripts) for "what if" scenarios". The underlying
> > database and checks would still work as is. The difference is that this
> > one package would be uncompress and install the parts which are needed.
> > Now if I had already upgraded package A or library B it would ignore
> > those particular packages.
> > 
> > When I upgraded to KDE 3 in Mandrake I placed all the relevant binaries
> > rpms in one directory and pointed the Mandrake installer to that
> > directory. Almost a one click upgrade to KDE 3. My suggestion is to
> > standardize that idea.
> > 

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

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.

rpm-4.1 permits concurrent database access. What that means, in principle
anyways, is that a "package of packages", aka "package bundle",
could be generated, and that
	rpm -Uvh *.rpm
can now be done in %post.

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.

> > Using the above example, I would download *one* file, enter the command
> > (easily added to Desktops) and the computer would take care of install.
> > This is even a simpler install than on Windows systems since the ideal
> > situation would be a *one-click* install, less authorization.
> > 
> > Dependency checks are a good thing, a mandatory thing, but the computer
> > should take care most of this behind the scenes on the desktop.
> > 
> > 
> >  
> > 
> > The second idea... have one standard rpm group naming structure.
> > 
> > The problem is quite clearly demonstrated by looking at all the
> > different description found here - a sample of the present state of the
> > naming structure.
> > 
> > http://rpmfind.net/linux/RPM/Groups.html
> > 
> > And I am not talking about different names but duplicated names. You
> > know it is a mess when people don't not know to use Application,
> > Applications, or use Application at all, or even use English. This
> > redundancy is seen throughout the whole list. Add to this it has spilled
> > over into the desktops and placement of desktop links. GIGO (garbage in,
> > garbage out)
> > 
> > Now when I am looking for a library, where should I look? "Libraries",
> > "System/Libraries" (Mandrake), "System Environment/Libraries" (mostly
> > RH), "Development/Libraries" (e.g., libxml, along with libxml-devel),
> > and I even have one in "Gnome/Development"
> > 
> > 
> > My recommendation is to create *one* three tier category naming
> > structure.
> > 
> > First level - System Category (App/Library/System/Development) this way
> > *all* libraries would be under Libraries, period.
> > Games, even thou an Application would need in its own top level do to
> > its volume.
> > 
> > Second level - General Category related to System Category
> > 
> > Third level - A group within the General Category
> > 
> > Examples
> > Development/Tools/Compilers
> > Development/Tools/IDE
> > Development/Languages/Perl
> > Development/Languages/Python
> > Games/Cards/Solitaire
> > Games/Arcade/FPS
> > Apps/Editor/vi
> > Apps/Office/Word Processors
> > 
> > 
> > Yes, people are using some of these, just make it into a standard.
> > 
> > First publish the standard list and what should go where and why. There
> > has to be one central authority for the naming structure otherwise the
> > problem will still exist.
> > 
> > Add to the rpmbuild program a qualifying check for the name so if it
> > does not qualify the person is warned it is not the standard. The list
> > would be kept as an external database for easy updates.
> > 
> > Add an option to the rpm program reassign group to a standard name -
> > empower user to clean up some of the mess.
> > 
> > Get the major distros to agree to and *use* this standard.
> > 
> > No need, even thou ideal, to do a blanket change, just phase the new
> > structure into new rebuilds.
> > 
> > Imagine how much a mess Unix and Linux would be if there was no standard
> > directory structure? I am just stating the obvious.
> > 
> > 
> > Thank you for your time, Gabriel Phoenix

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

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'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.

HTH

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC