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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Voice: 1-810-377-7469 Fax: 1-810-377-7363