From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tribhuvan Newsgroups: gmane.emacs.help Subject: Re: Software/HD ecology Date: Tue, 17 Dec 2002 22:24:01 GMT Organization: Optimum Online Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <3DFFA457.1020103@rcn.com> References: <041220020952400758%ajanta@no.spam> <56cfb0e3.0212041458.5eab182a@posting.google.com> <061220020416350201%ajanta@no.spam> <071220021155280606%ajanta@no.spam> <5ld6obj8il.fsf@rum.cs.yale.edu> <091220021652087216%ajanta@no.spam> <111220021101520860%ajanta@no.spam> <111220021253524057%ajanta@no.spam> <5l65u0i8zj.fsf@rum.cs.yale.edu> <111220022053507599%ajanta@no.spam> <87u1hjdwta.fsf@hurd.crasseux.com> <121220021324043990%ajanta@no.spam> <171220021132381961%ajanta@no.spam> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1040164014 16236 80.91.224.249 (17 Dec 2002 22:26:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 17 Dec 2002 22:26:54 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18OQAt-0004DN-00 for ; Tue, 17 Dec 2002 23:26:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18OQ9e-0002WG-05 for gnu-help-gnu-emacs@m.gmane.org; Tue, 17 Dec 2002 17:25:34 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!news-peer.gip.net!news.gsl.net!gip.net!c03.atl99!cyclone2.usenetserver.com!news.webusenet.com!news01.optonline.net!news4.srv.hcvlny.cv.net.POSTED!53ab2750!not-for-mail User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en Original-Newsgroups: comp.sys.mac.apps,comp.sys.mac.advocacy,comp.text.tex,gnu.emacs.help Original-Lines: 50 Original-NNTP-Posting-Host: 24.189.235.22 Original-X-Trace: news4.srv.hcvlny.cv.net 1040163841 24.189.235.22 (Tue, 17 Dec 2002 17:24:01 EST) Original-NNTP-Posting-Date: Tue, 17 Dec 2002 17:24:01 EST Original-Xref: shelby.stanford.edu comp.sys.mac.apps:349146 gnu.emacs.help:108234 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:4763 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:4763 Ajanta wrote: > What is needed: > > (1) To change the culture, so that every program comes with a safe and > complete uninstall option. > > (2) To empower the user, so he/she can easily discover what a > particular file on his/her computer is for, and where are all the files > related to the package xyz. I think you want to be able to specify the > source (GNU or FSF), name (emacs), and version (27.5) with intelligent > defaults, like all versions when none is specified. > pkg managers are an ideal model dealing with installing binaries, logging the multiple cp operations, version install date to /var. This allows for on demand reporting on all of the files that were copied to the system and their subsequent removal (or 'management' as the name pkg manager implies.) Only, this is absent when installing from source. When done compiling and doing "make install" according to your ./configure options, the output of "make install" has scrolled off conveniently to bit heaven. Thus, gaining lots of control over the _install_ process, we usually suffer later, not having a record of where everything went. If you're the only sys admin to ever touch the machines, and your memory is that good, well - there's got to be a better way. Just as the wonderful standards that have come to place during the _install_ process (aka automake, autoconf, pkgconfig (ala gnome)), would it really be too far out to suggest: * The relevant output of 'make install' be systematically * captured and stored to something like * (/var/log/auto-conf/pkg.version.log). Then, this formatted log * can be fed to another relatively simple script to report on or * operate on said files. * To work, those involved with distributing source may standardize * their make-install output to contain flags to be read by a piped * script, which will capture the relatively few lines relevant * to any subsequent package management. Tribhuvan