Re: RPM

[meierrj@frc.com]

Debians,

	I am a un*x guru, but a Debian newbie.  I apologize in advance if the
following three questions indicate avoidable ignorance of the proper usage
of dpkg.  I recently installed dpkg and dpkg-dev 1.4 only to find that it did
not remove the obsolete files of dpkg and dpkg-dev 1.2
(e.g. /usr/doc/dpkg/*.txt).

	A. How can one install debian packages without giving superuser
privelages to the person who assembled the package?

	B. How can one cleanly remove a debian package?

	C. How can one cleanly remove a debian package that failed to install?

I think the answers to these questions are serious enough to decide whether
Debian linux will grow or die.



>	Les Mikesell  les@mcs.com Wrote:
> What we really need is a way for the installer to set up and maintain
> a policy file that establishes the filesystem layout and where
> various programs are installed.  I don't see how being trapped
> into forever using the layout philosophy from some distribution
> is a strength for free software.

> I do realize that this would be an enormous job for existing packages
> but it seems like it could be done for new work.



	--- My understanding of traditional un*x package management. ---

A. How can one install packages without giving superuser privelages
   to the person who assembled the package?

	1. Superuser creates a directory /usr/packages/<newpackage> and gives
		ownership to tool.bin.
	2. tool (an unprivelaged user) extracts the tar file into directories
		[bin, lib, etc] under /usr/packages/<newpackage>.
	3. tool builds, compiles, configures, tests, etc. the package under
		/usr/packages/<newpackage>.  The ordinary permission system
		prevents tool (an unprivelage user) from unexpectedly
		interfering with any other package.
	4. (After satisfactory testing) Superuser symbolically links (or
		copies) the necessary files to where they are avialable to
		the community.

B. How can one cleanly remove a package?

	1. find(1) and remove all symbolic links to /usr/packages/<package>/...
	2. sudo -rf /usr/packages/<package>.

C. How can one cleanly remove a package that failed to install?

	1. find(1) and remove all symbolic links to /usr/packages/<package>/...
		[1. is seldom (never?) necessary, since they won't be generated
		 until the package installs correctly.]
	2. sudo -rf /usr/packages/<package>.

	[Most system administrators I know used personal scripts to implement
a variation of the above.  opt_depot is a set of scripts from Denver
University(?) that implement the above.]  [I personally add a directory
/usr/packages/<package>/original in which I put the original tar file, its
license, description, and a journal of installation, configuration, and
maintentance activity.]

	--- My understanding of traditional un*x package management. ---



--- My understanding of Windows and Windows95 answer to the above questions ---

A. How can one install Microsoft or other packages without giving superuser
   privelages to the person who assembled the package?
	You can't.  The package assemblers know everything.  Any problem is
your fault for having something they didn't know about on your system, such
as a package supplied by a competitor, or another product that depends on a
different version of a library.

B. How can one cleanly remove a package?
	You can't.  The package assemblers provide "uninstall" which will
tell you that it removed everything and destroy all traceability of the
files that it failed to remove, but still occupy space.

C. How can one cleanly remove a package that failed to install?
	You can't.  The package assemblers know everything.  Any problem is
your fault for having something they didn't know about on your system, such
as a package supplied by a competitor, or the results of a past installation
failure.

--- My understanding of Windows and Windows95 answer to the above questions ---



--- My understanding of the consequences of Windows and Windows95 answers ---

A. Installation of any package risks the destruction, disabling, or
   destabilizing of every currently installed package.  [This is one source
   of the Microsoft reputation for products that mysteriously stop working.]

B. With time, the disk accumulates cruft whose origin and purpose is unknown.
   The consequences of removal are likewise unknown, and seldom risked.

C. Every upgrade or installation carries the risk that the entire system
   will have to be reinstalled from scratch.  [This largely eliminates
   any software not received from a single source.  In other words, this
   largely eliminates free software.]

--- My understanding of the consequences of Windows and Windows95 answers ---
-- 
						Robert Meier

Microsoft has a software group colloquially know as the "Wreck a Nice Beach"
group.  Can you guess its official name and function?
	(hint-rot 13) Fnl vg frireny gvzrf snfg.
	(answer-rot13) Erpbtavmr Fcrrpu

FANUC Robotics North America, Inc.	Internet: meierrj@frc.com
Voice: 1-810-377-7469			Fax:      1-810-377-7363