[Kst] getdata library-ising

[Matthew D Truch]

> How should we handle packaging kst once getdata is removed?
> Should we be worried about distro package creators creating binary
> packages of kst lacking getdata support?  When we release kst source
> packages, should grab the latest getdata release, throw it into the kst
> source tarball and have the configure script build and install the
> "internal" version of getdata if it doesn't detect an external one?
> Were we do that, what sort of havoc would that wreak on depedency
> tracking package databases?  Should we trust distro packagers to create
> a getdata package and have the necessary dependencies for kst?  If they
> don't, would mild poking be sufficient to get them to do so?

Speaking as the official Fedora and EPEL (RedHat Enterprise
Linux/CentOS) kst maintainer, there is zero issue in removing getdata
from the kst source and putting it in an external package which kst
would depend on (if kst were to have getdata capabilities).  As long as
libgetdata is packaged in a sane way (i.e. you used the auto* tools so
that configure can be passed things like destdir and prefix and the like
so distributions can put the libraries and headers where they belong) it
will be trivial for all distributions to include libgetdata.  From what
I know about Fedora packaging and from what I gather hearing about
packagers at other distributions, it's always easy (and almost a
pleasure) to package "sane" packages.  It's the annoying ones where you
have to write patches and hacks to make it install things in the proper
location that is annoying and frustrating.  And makes you question your
reasons for being a packager.  

Once this change to kst/libgetdata is made, a polite poke to all the kst
maintainers in the various big-name distributions would probably be the
best thing to do.  It shouldn't be too hard to find their email
addresses online.  In my case, merely posting to the kst mailing list
will suffice.  

-- 
"Hermits don't have peer pressure."
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt at truch.net
http://matt.truch.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20080610/a5197904/attachment.pgp