groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Re: a couple of fixes to html.cc


From: Bernd Salbrechter
Subject: Re: [Groff] Re: a couple of fixes to html.cc
Date: Thu, 16 Dec 1999 20:52:07 +0100 (CET)

References: <address@hidden>
        <address@hidden>
        <address@hidden>
        <address@hidden>

Sorry abbout the late answer.

Werner LEMBERG <address@hidden> wrote:

> [About naming GNU troff `gtroff' or `troff']
> 
> > > Anybody on the list who has suggestions how to improve this?  I
> > > mean the inconsistency, not the automatic process of checking the
> > > `g' prefix (which can be changed rather easily using the
> > > AC_ARG_PROGRAM autoconf function).  My idea is to always use `g'.
> > 
> > I wonder whether the rule for installing binaries should be to
> > install components as geqn, gtbl, g..  etc.  Only place symbolic
> > links from their non g counterparts if "troff" already exists?  If
> > we really need the old names?
> > 
> > This way the g named components will appear the same as previous
> > releases.  On another point if the install directory has changed --
> > should the install warn that another groff is elsewhere?  I had this
> > for a time on my RH-5.2 where /usr/bin/groff was the old copy and
> > /usr/local/bin/groff is where the new copy went.
> 
> What do you think about the following algorithm:
> 
>   0) The groff package will always use the `g' prefix.

A good idea to have a consistent naming for all programs in a package.

...
>   2) Check whether a binary called `gtroff' is installed.  If yes
>      check whether the installation directories are the same.  If not,
>      emit a warning that another groff package is on the system which
>      can cause conflicts.  [Shall `make install' abort in this
>      situation?]

I say no. 'make install' should install additional versions of groff.
A warning is OK.

If the environment is set right, several groff versions can peacefully
coexist on one system. For preparing 'chroot(1)' environments it is
handy to install packages at different locations on one system (even
different versions).

> 
>   3) Install groff.  Make a link gtroff->troff only if HAVE_TROFF
>      isn't set.  If HAVE_GTROFF_AS_TROFF is set, remove the old link
>      and use the old link's directory for the new link.  Do the same
>      for geqn, gtbl, etc.

This will be dangerous, if more than one version is installed.

> Are there any GNU guidelines covering such tricky situations?

About old Versions:

As far I have understand the papers come with 'autoconf', there is
a way to guess the 'prefix' from an already installed version (see
AC_PREFIX_PROGARM).  But rules for handling more than one version
on a system are missing. Curious but most GNU Software behaves
quite well in that case. I have done this several times, when trying
a new version in a private (not as root and -prefix=$HOME/test_inst)
installation.

I would vote for adding the following rules to 'standards':

1. It should be possible to install different version of a package
parallel. As long as '--prefix' is set to a different place.

2. A warning should be written at installation ('make install'), if an old
version exists and is not replaced by the installation.

3. When overwriting an old version, make sure that all old parts get
overwritten or removed, if the parts are renamed.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]