Re: Making demo programs more evident...

[Petr M. <mi...@ph...>]

> > Hmm on "unix" .. "make install" does not install demos, so there is not
> > "properly" installed unix.
>
> As far as I'm aware, none of our makefiles installs the demos anywhere.
> Nor did any of them, ever.


Yes, and that's what I always complain about: there is no "make install all"
that would do automatically such an install as I packaged for OS/2 and
Windows packages -- ie including all docs, demos, INSTALL and README files.

> > Using a rpm package for gnuplot ... turns you to demos for an old
> > gnuplot.
>
> Huh? That only applies if you look at an old, now outdated RPM, obviously.
> There'll be only *one* binary RPM of gnuplot installed in any given box.

Are you sure? I have two.

$ rpm -q gnuplot
gnuplot-3.7.3-106
gnuplot-4.0.0-1

The former by SUSE, the other by
	checkinstall make install-strip

Of course, gnuplot's own "make install-strip" sucks for the above reasons
(no docs, no demos, no FAQ, ...).


> > INSTALL writes ./configure does not want to decide where to put demos --
> > why not?
>
> INSTALL says so, and it's written in there for said "ordinary people" to
> see.  So they'll know there are demos they may want to install, at a place
> of their choosing.

No, they don't know, and no, they won't read it -- or stop reading before
"how to install demos".

I don't understand why you don't want to support ordinary people who wish to
do
	make install

and have installed really everything what gnuplot offers.

Look at other software packages -- their "make install" installs more docs,
faqs, demos. Why should gnuplot not do this?

Actually -- if we don't let install all, we have more troubles answering
FAQs...


> > /usr/local/share/gnuplot/... gnuplot is already writing there, why not use
> > it for demo?
>
> That would be the right place for them to go for a non-RPM local
> installation from sources.  I.e. if we make a "install-demos" target, or
> have the default 'install' put them up anywhere, $(pkgdatadir)/demo is
> where that'll be.
>
> But it's not the place the existing binary packages made by third parties
> put them.  SuSE Linux, e.g., puts such files below
> /usr/share/docs/packages/<name>, not /usr/share/<package>, and they may
> prefer to keep it that way.  But since there's no
> /usr/local/share/docs/packages in a Linux system, we can't easily
> duplicate that, and probably we shouldn't.

Look this way: I want to install new gnuplot for me and just me, on a unix
box. Thus I do:

	./configure --prefix=$HOME/usr

Now I want all goes into a useful directory there. Why not

	$HOME/usr/share/doc/gnuplot-4.0.0/
and thus:
	$HOME/usr/share/doc/gnuplot-4.0.0/ with gnuplot.pdf, ...
	$HOME/usr/share/doc/gnuplot-4.0.0/psdocs
	$HOME/usr/share/doc/gnuplot-4.0.0/demo


Similarly,

        ./configure --prefix=/usr/local
would do
       $HOME/usr/share/doc/gnuplot-4.0.0/  with gnuplot.pdf, tutorial.pdf,
				gpcard.pdf, FAQ
       $HOME/usr/share/doc/gnuplot-4.0.0/psdocs
       $HOME/usr/share/doc/gnuplot-4.0.0/demo


What about accepting this scheme?


> And remember that as soon as we put a pointer to the locally installed
> copy of the demos into the online help, odds are distributors will manage
> to break it.  But it'll likely be us who get the complaints about it.

Don't put the exact pointer, but say "see gnuplot doc installed on your
system".


> Those people who care, know.  Those who build RPMs at distributors
> included.

$ rpm -qa | wc -l
   1464

If every application of those 1466 wastes 700 KB as gnuplot, it is 1 GB of
wasted HD. That's not negligable.


> OTOH, HD space is less than 0.01 USD or EUR per MB these days...

But:
1. You cannot easily change hard disk in your notebook.
2. You cannot change/add hard disk in computer of your company.
3. You cannot add new hard disk for whichever other hardware reason.

---
PM