From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 947 invoked from network); 7 Jul 2000 12:46:09 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Jul 2000 12:46:09 -0000 Received: (qmail 19540 invoked by alias); 7 Jul 2000 12:46:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12189 Received: (qmail 19533 invoked from network); 7 Jul 2000 12:46:01 -0000 Date: Fri, 07 Jul 2000 13:45:33 +0100 From: Peter Stephenson Subject: Re: adding a toplevel zsh.spec.in file In-reply-to: "Your message of Fri, 07 Jul 2000 12:53:17 BST." <20000707125317.A1626@thelonious.new.ox.ac.uk> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Message-id: <0FXB00E50VFWXR@la-la.cambridgesiliconradio.com> Content-transfer-encoding: 7BIT > Hi all, > > I would like to add a zsh.spec.in file to the toplevel directory so > that any tarball releases or CVS snapshots can immediately be built > into RPMs with > > $ rpm -ta zsh-3.1.x-dev-y.tar.gz > > Are there any objections to this? If not there are a few issues to > clear up: > > - Do we also bundle a zsh.spec in releases? I vote yes, otherwise > the whole exercise is a bit pointless. That won't be a problem. Just add it to .distfiles. > - Should zsh.spec be included in the CVS tree? Yes goes against the > grain, since all other auto-generated files aren't, but no means > that CVS snapshots can't be built immediately as above. It's not worth it; you can't bundle a raw CVS tree anyway, you have to run preconfig. Get that to do any pre-configuation stuff. > - I would like to include some sample startup files for a typical > RedHat box. I already have these - taken from an official RedHat > zsh rpm, and then much improved (mainly through suggestions from > Bart). Would it be OK to add these in a new StartupFiles/RedHat > directory? Or is it time that the current StartupFiles files > (written for 2.7) got a rehaul anyway? It's ancient, it really should be completely rewritten and preferably divided up into indiviual files doing different things, with any compctl stuff stuck in a subdirectory for legacy code. -- Peter Stephenson Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070