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-2.2.0.1
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
package.
Thanks for your time!
Peter
Reply to: