Re: Simplifying package installation.

[whizbang <whizbang nbnet nb ca>]

James Green wrote:

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

wouldn't that be great - another package 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.
>

me too.

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

um... uh... i can't think of a unix with no package system (besides
slackware). of course i'm not all knowing

>
> 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!
>

nor the end user trying to decide which distribution/apllications they want to
run

>
> No, software itself is distribution-neutral. What runs on RH5.2 should
> also run on, or least have a version for, Debian.

and solaris (and jeez, i wish i could find it for irix 5.3)

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

unless you only plan on getting the software from the same vendor/distributo
that you got the OS from - kind of limiting tho

>
> 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?
>

is rpm proprietary? i thought it was gpl (don't personally know what apt is,
but from the context i would guess it is as well). rpm also has a mechanism
for packaging source (not that i'm plugging rpm - i just am not familiar with
other packagers)

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

a few months ago i would have thought you were crazy - one of the diggest
differences between the major unixes is their package systems, and there would
be no way we could convince a vendor like sun or ibm to trash their package
system in favor of a new, free one. however, i never would have imagined that
sgi would ditch irix in favor of linux, either. perhaps there is hope that a
free package manager could become part of the non-free *nix systems.  it would
certainly be a win for the desktop(s) that tied themselves to a package
system, and a loss for the open group and the motif/cde way.

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

i think i've got the market cornered on gibberish, thank you very much ;-)

>
> Any thoughts?
>
> --
> James Green
> http://www.cyberstorm.demon.co.uk/
> Home of the demon.tech.modems 56k FAQ.
>
> --
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.

Dr. Whiz-Bang
whizbang@nbnet.nb.ca
Don't waste your time here --> http://whizbang.penguinpowered.com