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

Re: Bug#753620: wishlist: idl/gdl-written software

* Оlе Ѕtrеісhеr [2014-07-04 18:20:27 +0200]:
> Sergio Gelato <Sergio.Gelato@astro.su.se> writes:
> > * Оlе Ѕtrеісhеr [2014-07-04 14:45:14 +0200]:
> >> Sylwester Arabas <sarabas@igf.fuw.edu.pl> writes:
> >> > - should idlastro become a dependency of gdl?
> >> 
> >> GDL should be a requirement of the package(s). 
> >
> > I'd vote for a simple Recommends:, to cater for those who want to use
> > the packages in some other way (e.g., in conjunction with proprietary
> > IDL).
> In a Debian world, these packages only work with GDL, so GDL is required
> (and not just recommended).

OK, maybe it really should depend on gnudatalanguage | idl-interpreter
(or whatever the virtual package name would be), just like some Java
libraries depend on default-jre-headless | java5-runtime-headless .
I have no ambition to dictate Debian policy so I'll bow out of further
discussion on this point. There's always equivs anyway.

> I worry a bit that otherwise GDL is just used as an excuse to ship
> packages that require non-free software in main.

I don't think that should be a concern: wouldn't you agree that if the package
doesn't work with GDL it shouldn't recommend (much less depend on) GDL? It
then falls outside the scope of this discussion since the reasons (if any)
to include it in Debian would not be related to GDL.

> If these packages work with GDL: why should one use IDL then?

If a library can be called from C, why should one want to call it from C++?
The answer is going to depend less on the library itself than on the uses
it is being put to.

Just to make it clear: I'm not asking for anyone to package idlastro and
friends. If someone does, then I'll consider using the packages and will
be grateful if they meet my needs. I think I can see some value in:
-- providing a policy and/or a canonical example for how to package
   GDL add-ons (as we have for Perl, Python, Java, Ruby, Octave, etc.)
-- testing idlastro etc. with GDL and resolving or documenting any
   incompatibilities found.
The former would make it easier for me to produce private packages of
anything that I need and that (for whatever reason, including the ones
we've discussed here) does not make it into Debian. The latter might
help make GDL a viable alternative to proprietary IDL; right now the
users I support don't perceive it as such. I leave it to those who
would actually do the work to decide whether it's worth their time.

Reply to: