delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2002/06/10/16:26:30

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
From: "Robert Collins" <robert DOT collins AT syncretize DOT net>
To: <cygwin-apps AT cygwin DOT com>
Subject: RE: package offering: gnupg
Date: Tue, 11 Jun 2002 06:24:32 +1000
Message-ID: <000d01c210bc$d484e350$0200a8c0@lifelesswks>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
In-Reply-To: <20020610153027.GI6201@redhat.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000


> -----Original Message-----
> From: cygwin-apps-owner AT cygwin DOT com 
> [mailto:cygwin-apps-owner AT cygwin DOT com] On Behalf Of Christopher Faylor
> Sent: Tuesday, 11 June 2002 1:30 AM


> >I'd suggest not depending on the _install_info virtual 
> package. It's a
> >neat hack, but IMO should a fallback, not the primary tool. 
> 
> Hmm.  I'm not sure how Rob expects me to react to this, but this is
> pretty annoying.

I'm sorry you find it so.
 
> I'd suggest ignoring Rob's suggestion and relying on the _install_info
> package.  It was specifically designed to eliminate the 
> requirement for
> everyone and their brother to reinvent the wheel with their own
> postinstall scripts that rebuild the info directory.

But it only reacts when a package on sourceware is updated. That means
that test packages on peoples private sites must still have individual
install-info scripts. And that when someone reinstalls package foo (or
removes, waits a couple of weeks and installs again) in offline mode,
then they still need an install-info script. 

And don't forget removal scripts to remove the entries from the
directory when the package is removed.
 
> The "hack" (thank you very much) 

I did not mean "neat hack" in a derogatory sense. The install-info
requirement detecting code works. BUT. It's also an incomplete solution
- as any centralised solution will be in this case. Anything short of
adding an install-info postinstall script to each package on the fly
will be incomplete.

> is doing what computers are 
> supposed to
> do.  It's eliminating the burden of your having to do something and,
> more importantly, it's eliminating the possibility that you would do
> something wrong.  You don't have to worry about figuring out how to
> run install-info.  You don't have to worry about screwing up the 'dir'
> entry if you got it wrong.  It's done for you automatically.

But not in the 2 cases above, which like it or not are not uncommon.
 
> (And, yes, I'm just *waiting* for the obvious response to this
> paragraph)

Whats the obvious response? (I'd hate to let you down :} ).

Rob

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019