Re: [MinGW-dvlpr] RFC: lpr

[Keith M. <kei...@us...>]

On Saturday 12 September 2009 04:12:54 Charles Wilson wrote:
> The value to me of the NEWS file, for very active projects, is I
> don't have to wade thru six months' worth of commit records in
> gcc's ChangeLog to learn that VTA support has been merged into
> gcc-4.5.0.

Absolutely.  The value of the NEWS file, for *any* project, is to 
provide an itemised summary of feature changes between releases.  If 
we ever add new features to lpr-enhanced, then we can add a NEWS 
file for this purpose.

> >   DOC_DISTFILES = README
> >   LIC_DISTFILES = AUTHORS COPYING
>
> I think I'd put the AUTHORS file into the DOC package. The COPYING
> file contains your name and the license/disclaimer. IMO that's
> sufficient,

Okay, thanks.  I was undecided, but I think I'll change it to:

  DOC_DISTFILES = README AUTHORS
  LIC_DISTFILES = COPYING

> 'make bindist' didn't quite work.

Arrrrgh!  It did for me, when I configured only with --prefix='', and 
defaults for localstatedir and sysconfdir, but it breaks when I use
explicit --prefix=/usr --localstatedir=/var --sysconfdir=/etc.  
Thanks for your patch; I've applied it partially (see below), with 
some comment changes.

> I modified as shown below.  My 
> proposed change is fine for msys and cygwin builds, but if you use
> the mingw formulation where
>         --prefix=`cd /mingw && pwd -W` \
>         --sysconfdir=`cd /etc && pwd -W` \
>         --localstatedir=`cd /var && pwd -W`
> then it would break. But why would you want to do that?

I can't imagine; there's nothing in this package which can survive in 
a pure mingw32 subsystem.

> Also, one of the commands left $CWD in the wrong place, so I put
> it in a subshell.

Huh?  I guess you mean:

  cd $(STAGED)${bindir}; rm -f lp lpr

The scope of the cd command *should* encompass only the following 
commands on the same logical line in the Makefile, (the rm command 
in this case).  If it persists beyond, then your implementation of 
`make' is broken.  I've omitted that part of your patch, pending 
further discussion.

> One other comment: I'm not sure I'd want the -bin package to
> include /etc/printcap.  Without scripting support in our
> installer, we really can't automate the installation of
> configuration files, nor protect the end-user against clobbering
> their customizations.  At least when installing "live" we could
> protect an existing /etc/printcap by installing the new one only
> as /etc/printcap.new if /etc/printcap already exists.  But for the
> -bin package, so such luck.

Good point.  Maybe we should just omit it from the installation 
entirely.  If we do install it, then it should be conditional on a 
prior `test -f' failing, and we should remove it from the staged 
install, prior to cutting the bindist tarball.

-- 

Regards,
Keith.