Re: How much interest in a "debian-science.org" repository?
On Thu, 2006-07-20 at 13:53, Daniel Leidert wrote:
> Am Mittwoch, den 19.07.2006, 13:03 -0400 schrieb Kevin B. McCarty:
>
> [..]
> > That reminds me of another question I had. Maybe it's too early to
> > bring up but I'll ask it anyway.
> >
> > What would be the best way to organize the archive by section? The
> > usual divisions "main contrib non-free" are fine for Debian, but one
> > of the main reasons an unofficial repository is needed is the
> > often-poor state of care to licenses in scientific software that makes
> > them unsuitable for Debian's archive. Probably the only software in
> > "main" in the repo would be either things undergoing testing on their
> > way to the Debian official archive, or Free software that's too
> > obscure to package for Debian. (I'm thinking of CERN's "patchy" as an
> > example for the latter.)
> >
> > So I was thinking perhaps a division by field makes more sense -
> > "analysis astronomy biology chemistry physics" etc. A typical
> > sources.list line might then look something like
> >
> > deb http://www.debian-science.org/ physics analysis
>
> I heavily vote against this.
>
> > Maybe some packages could be made available under more than one field
>
> And this is the reason. It would make it more complicated to get or even
> _find_ packages.
>
> > (e.g. ROOT under both physics and analysis)? After all, ROOT and
> > (e.g.) PAW aren't intrinsically physics software (unlike say GEANT),
> > they're just traditionally used by physicists. Comments?
>
> I really vote for using the main/contrib/non-free section model. This
> would also help to see, which packages might be worth a try to get them
> into Debian officially, which should be the goal in every case.
>
An answer in this thread said, scientist often don't care about
licenses. And often they are allowed to do so. Often applications have
exceptions for non-commercial use or usage for research tasks. The
latter is easily proven when working for an institute or university.
As a conclusion, separating science applications into
main/contrib/non-free does not make much sense in these cases. As
scientist I can put the most into main.
So a high level classification into something like libraries, plotting,
visualisation, WEB, GUI, common, ... (only a collection of items as
example) would be more appropriate I think.
Kind Regards,
Thomas
Reply to: