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

Re: Version specific packages

"Marcelo E. Magallon" wrote:

> On Wed, Jan 27, 1999 at 09:42:11AM -0500, Peter S Galbraith wrote:
> > Sure.  Gri is a programming language in the same sense as
> > gnuplot.
> [ Out of curiosity, what exactly does gri do? ]

Description: a language for scientific graphics programming.
 Gri is a command-driven application, as opposed to a click/point
 application.  It is analogous to latex, and shares the property that
 extensive power is the reward for tolerating a modest learning curve.  Gri
 output is in industry-standard PostScript, suitable for incorporation in
 documents prepared by various text processors.  .
 Gri can make x-y graphs, contour-graphs, and image graphs.  In addition to
 high-level capabilities, it has enough low-level capabilities to allow
 users to achieve a high degree of customization.  Precise control is
 extended to all aspects of drawing, including line-widths, colors, and
 fonts.  Text includes a subset of the tex language, so that it is easy to
 incorporate Greek letters and mathematical symbols in labels.
 The following is a terse yet working Gri program.  If it is stored in a
 file called 'example.gri', and executed with the command 'gri example', it
 will create a postscript file called 'example.ps' with the graph.
   open file.dat        # open a file
   read columns x * y   # read the 1st column as x and the 3rd as y
   draw curve           # draw the data and autoscale the axes
> > But if the `replaces: gri-VERSION' line will confuse some Debian packaging
> > scripts, then I will remove it and warn users in README.debian that there
> > is no dpkg dependence protection if they install gri-VERSION (which will
> > over-write files owned by the gri package).
> Perhaps this helps:
> 	/usr/bin/gri -> /etc/alternatives/gri -> /usr/bin/gri-some-version
> 	/usr/bin/gri-version-a
> 	/usr/bin/gri-version-b
> 	/usr/lib/gri-version-a
> 	/usr/lib/gri-version-b

Seems a little complicated to me...

> I guess I'm asking: does gri-version-a really NEED to replace gri (or the
> other way arround)?

gri-2.2.0_2.2.0 contains:

-rwxr-xr-x root/root    800516 1999-01-26 20:39 usr/bin/gri-2.2.0
-rw-r--r-- root/root    180889 1999-01-26 20:39 usr/share/gri/2.2.0/gri.cmd
-rw-r--r-- root/root       363 1999-01-26 20:39 usr/share/gri/2.2.0/startup.msg
-rw-r--r-- root/root      1592 1999-01-14 15:08 usr/doc/gri-2.2.0/{README...}
-rw-r--r-- root/root      1398 1999-01-14 15:38 usr/man/man1/gri-

gri_2.2.0 contains the a lot more stuff (HTML and postscript manual, 
info, emacs mode) as well as the _same_ binary and .cmd files:

-rwxr-xr-x root/root    800516 1999-01-26 20:39 usr/bin/gri-2.2.0
lrwxrwxrwx root/root         0 1999-01-26 20:39 usr/bin/gri -> gri-2.2.0
-rw-r--r-- root/root    180889 1999-01-26 20:39 usr/share/gri/2.2.0/gri.cmd
-rw-r--r-- root/root      1398 1999-01-14 15:38 usr/man/man1/gri.1

As such, I don't want gri_2.2.0 and gri-2.2.0_2.2.0 installed at
the same time because gri_2.2.0 includes the gri-2.2.0_2.2.0
binary.  But having both gri_2.2.1 and gri-2.2.0_2.2.0 would be okay.

> gri (<some-version>) should conflict with gri-<some-version>, like this:
> Package: gri
> Version: 3.14
> Conflicts: gri-3.14
> Package: gri-3.14
> Version: 3.14
> Provides: gri

This would be the way to spell out the dependences when using alternatives?
I would still have a `Conflicts' line with an non-official

Thanks for your time!


Reply to: