From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23597 invoked from network); 24 Oct 2005 12:32:59 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 24 Oct 2005 12:32:59 -0000 Received: (qmail 83639 invoked from network); 24 Oct 2005 12:32:53 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 24 Oct 2005 12:32:53 -0000 Received: (qmail 27847 invoked by alias); 24 Oct 2005 12:32:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21921 Received: (qmail 27837 invoked from network); 24 Oct 2005 12:32:49 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 24 Oct 2005 12:32:49 -0000 Received: (qmail 83348 invoked from network); 24 Oct 2005 12:32:49 -0000 Received: from ns9.hostinglmi.net (213.194.149.146) by a.mx.sunsite.dk with SMTP; 24 Oct 2005 12:32:48 -0000 Received: from 212.red-80-35-44.staticip.rima-tde.net ([80.35.44.212] helo=localhost) by ns9.hostinglmi.net with esmtpa (Exim 4.52) id 1EU1VS-0004DW-96; Mon, 24 Oct 2005 14:32:50 +0200 Date: Mon, 24 Oct 2005 14:33:47 +0200 From: DervishD To: Peter Stephenson Cc: zsh-workers@sunsite.dk Subject: Re: zshall.1 Message-ID: <20051024123347.GC355@DervishD> Mail-Followup-To: Peter Stephenson , zsh-workers@sunsite.dk References: <20051024080141.GA18213@fermat.math.technion.ac.il> <5ed187370510240452l26ce144cyf23d0b3c7decf259@mail.gmail.com> <20051024130020.341f1235.pws@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20051024130020.341f1235.pws@csr.com> User-Agent: Mutt/1.4.2.1i Organization: DervishD X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns9.hostinglmi.net X-AntiAbuse: Original Domain - sunsite.dk X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - dervishd.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Hi Peter and Zvi :) * Peter Stephenson dixit: > "Zvi Har'El" wrote: > > I don't know better how people use it, but the usage has to be consistent. > > If you install your zsh as zsh-dev, and man zsh-dev, man zsh-devoptions etc > > all give you the new manual page, man zsh-devall should do the same! > > That wasn't quite the point... > > At least one of those prefix/suffix things was introduced so you > could install zsh in one place (where it would never be used), > package it up there, then have the package install it in the normal > place. In other words, it would never be run in the place where it > was actually installed, it always got moved first. In autoconf, the program-prefix, program-suffix and program-transform-name were introduced to modify the names of the binaries, and in fact if this facility is used to install the software into a temporary place to package it afterwards, then it will not probably work (if you transformed DATADIR, for example). If you want to install the software in a place suitable to make a distribution package, then you should use the "DESTDIR" variable, at least this is the common practice with autoconf-based software. The real problem is that autoconf doesn't force the developer to change the names even when program-whatever options are used. So there is really NO WAY of telling if those options are intended to modify installation names or to do packaging: the developer can use it for both things (that's one of the million reasons why I wrote MOBS for my projects). If the options were called 'transform-names', 'add-prefix' and 'add-suffix', the intention would be much clearer, but with the current name I wouldn't make a bet. Right now using those options is very dangerous because, depending on the developer, they can apply ONLY to binaries, they can apply only in the name level and not in the code level (I mean, you install "myprogram" with a transformed name of "myprogname-suffixed" and you don't know if it will look for data in $datadir/myprogname or $datadir/myprogname-suffixed), or probably you can only modify the $prefix so you can install it in any directory to package it. There is no way of knowing. What I would suggest here is to document the behaviour or simply don't honoring any transformation and issue a warning if any is provided. If zsh installation names can be modified, they have to be consistently and allow documentation names to be modified accordingly. Another, better solution, is to get rid of the autoconf nightmare, but unfortunately there aren't many replacements out there (and not, MOBS is not *exactly* an autotools replacement). The less intrusive change may be to change ALL installation names (including the hardcoded paths, if any, that zsh uses) when a transformation is requested, and document this behaviour. Otherwise don't allow transformations, if this will lead to less surprises to an advanced end user (advanced in the sense of autoconf, not zsh). Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to...