Re: Simplifying package installation.

[James Green <gnome cyberstorm demon co uk>]

On Fri, 27 Aug 1999, Derek Simkowiak wrote:

[ snip ]

> 	I agree: falling back to .tar.gz means there is no package
> management at all.

Currently. One wonders if Corel are extending Debian's apt, or creating
their own management system.

[ snip ]

> 	More to the point: should the package management system be part
> of Gnome or part of the O.S.?

Since packages are run by the OS and not the environment, they should be
installed and maintained by the OS, and GNOME/KDE/whatever can provide
front-ends.
 
> 	Since people will install applications other than just Gnome
> applications, I would say the package management should be part of the
> O.S., not part of Gnome.

Yup.

> 	If some crappy-ass Unix variant doesn't have a package database
> that provides all the features of an RPM or DEB system, and the "Gnome
> Installer" falls back to .tar.gz as a last resort, then that is the fault
> of the O.S., not the fault of Gnome.  I still think .tar.gz is a good
> fallback.

So do I, with reservations.

I mean, what are we trying to do here? Package management has always been
to me a saw point on Linux/Unix. Let's face it, distributions are often
chosen for their package management functionailty, be it rpm, apt/deb, tgz
or whatever. This is splitering the distributions and of course does not
help distribution of software!

No, software itself is distribution-neutral. What runs on RH5.2 should
also run on, or least have a version for, Debian. Both distributions will
run the same software, the software is derived from the same courses and
authors, so why the hell should the author have to build a tarball for the
sources, an rpm for RedHat-based systems, and also (or get someone else to
build) .debs? No, software packaging and distribution should not be based
upon which distribution you are running.

The solution isn't exactly easy but imo needs doing before more than the
current trickle of Windows users start turning to Linux. These people want
to be able to download pre-compiled or source packages (one file contains
either of these) and be able to (optionally build and) install using a
point-and-click UI, perhaps with 'Wizard'-like functionality too, much
like InstallShield on Windows.

The end-user most likely doesn't want to see dozens of 'make' and
'configure' lines scrolling up the screen. The end-user also doesn't want
to have to decompress a file into /usr/src/whatever, cd into it,
./configure; make; su root; make install; /sbin/ldconfig; logout either.

Most importantly, the above set of people don't want to have to know the
command-line options to do things.

Of course, we mustn't forget developers either though. They need to see
make and configure and debugging output. And of course let's not forget
those of us who want to learn both the traditional rpm-based installation
method and that of GNU-configure and make methods. So we see three classes
of end-users here:

1. Developers;
2. Potential Developers, installing manually;
3. Non-developer end-users.

For (1.), we have cvs, plus of course the traditional monthly tarball
snapshots. The same applies to (2.) except that (2.) may just use release
tarballs instead.

For (3.) we see the need to hide what (1.) and (2.) what to see, and the
obvious solution is to provide a GUI.

All this is fine, but do any of the existing solutions fit the bill for
all three? No. Tarballs and cvs work for (1.) and (2.), not (3.), while
rpm and other package managers work to some degree of user-friendliness
for (3.).

Finally, package management is not distribution-neutral.

So, we have a set of systems that do the job, but at a price. What we need
is a system of packaging up both source and pre-compiled binaries into
seperate files but that are not distribution specific. This raises obvious
concerns such as how to compile on a RedHat 6 system and package it up for
installation on all distros, and that's something that would need sorting
out.

What we need therefore is a standard system common across Linux/Unix. The
main commonality is that of GNU. So why not take the GNU source-packageing
system, and extend it to cover the points raised above, and include the
good bits of the proprietary systems such as rpm and apt?

Ideas:

* Extend or modify existing configure to have an text file of dependencies
which can be read from outside the package, e.g. <packagename>.deps. This
would allow the system to identify and download (prompting where
applicable dependencies; how many times have you downloaded something only
to hit the net again to grab a dependency or upgrade a dependency?) it. 
This idea would come from what I understand of apt.

* provide versions of the package as pre-compiled binaries and also source
files for local (or remote) compilation. This may have to be extended on a
per-distribution system (e.g.
<s/w-name><s/w-version>-<distro-name>-<distro-version>-bin.gnupkg).

* maintain a database of installed files for easy dependencies-checking,
upgrading and deinstallation; rpm can be seen here as fitting the bill.

* Provide a single cmd-line front-end for package management to maintain
cross-distribution maintainability.

* GNOME/KDE/whatever front-ends to the above front-end so the user can
point-and-click to (optionally build and) install the packages.


The principal of course is to do away with rpm and apt and any other
proprietary package management systems and base ourselves on a GNU way,
common to all distros and Unices alike.


Please note that if the above sounds like a load of jibberish, don't
worry, it's me :) I've only been running Linux effectively since the start
of the year and haven't yet developed for it, so my knowledge of these
things is very limited. But hell, since when has developmental-knowledge
been neccessary for good ideas..?

Any thoughts?

-- 
James Green
http://www.cyberstorm.demon.co.uk/
Home of the demon.tech.modems 56k FAQ.