Understanding Packages

[cbbrowne-HInyCGIudOg= at public.gmane.org]

> Hello: I'm trying to understand what a "package" (.tar) is, why
> applications are (usually) supplied as a package, and how/when the
> components of the package are loaded and executed when the
> application is active.  If you know of a tex t that really explains
> this, giving me the URL (or other reference - say a book ) would be
> the best way to answer this query.

".tar" files are not generally 'packages;' they are merely bundles of
files that have been assembled together.

On Unix, the program 'tar' has long (for decades!) been used to assemble
bundles of files together to stream onto some sort of serial output
device, often a tape.  Thus, 'tar' is short for 'tape archiver.'

Throw in data compression (in GNU tar, the "-z" option) and this
provides functionality relatively similar to PC "archive" utilities like
pk-arc, lh-arc, and 'zip.'  It might be a reasonable idea to use Zip
instead of tar, but hey, there's 20-odd years of history of using tar.

But none of this is really about "packages."  The typical "packaging"
systems are:

 a) For numerous derivatives and relatives of Red Hat's distributions,
    "rpm."

    RPM doesn't use tar at all; it uses gzip (which just does
    compression), and cpio (which is similar to tar, albeit functioning
    differently).

 b) For Debian and its derivatives, the tool "dpkg" is used for package
    management.

    It uses gzip for compression and "ar" (a _very_ basic archiver)
    which then stores tar files containing the files mahaged in the
    package.

With both RPM and dpkg, they build package archives that contain the
files required to run the application, along with files to configure it,
along with metadata to describe what other packages a given package may
depend on.

You use rpm/dpkg to install a package; this leads to it checking
dependancies, installing the various files, and storing the list of
files in a "package database" so that you can track what all is
installed, and even deinstall packages in a coherent manner.

> I guess that much Linux software is written in C, and I've noticed
> that C doesn't allow functions to be defined (nested) within other
> functions; MAIN and all the functions that it calls, and all the
> functions that they call, are at the same hierarchical level, with
> data/results being passed between them via parameters of the
> functions.  I guess that this could be the explanation for why
> applications come as a package of C functions, even though only one
> (or a few) of the many functions that comprise the package are called
> (callable) by the user ?

It happens to be _convenient_ to deploy common libraries of functions as
C libraries because they may be readily linked to just about any
language you might care to use.

> I need to know, because I'm in the middle of revising a paper
> extolling the virtues of nested, vs. non-nested, environments; I want
> to say something about C and Linux (and perhaps Micro$oft Windows),
> and of course I want what I say to be accurate.

Hierarchies of C functions are fairly much "flat" so you won't have much
relevant material to work with.

You can extoll the virtues of whatever you like; if you want to talk
about "nested environments," C obviously won't be a case of this.  You
may need to look to languages like Smalltalk, Lisp, and the likes for
examples of that.

This doesn't really fit with the packaging systems without looking at
things really rather obliquely...
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/emacs.html
I am not a number!
I am a free man!
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml