Re: How much interest in a "debian-science.org" repository?
Am Sonntag, den 23.07.2006, 22:35 +0200 schrieb Thomas Walter:
> On Fri, 2006-07-21 at 01:32, Daniel Leidert wrote:
> > Am Freitag, den 21.07.2006, 00:03 +0200 schrieb Thomas Walter:
> > > On Thu, 2006-07-20 at 13:53, Daniel Leidert wrote:
> >
> > [directory/section structure proposal - freedom vs research field]
> > > > 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.
> >
> > Well, scientists (=users here) are not those guys, who will have a look,
> > which packages might be worth (and allowed) to put into Debian. So this
> > is not related to what I said.
> >
>
> But this seems to be important and as far as I understood the main
> suggestion of this thread: "Collect the science software at one place
> and avoid spreading over several sites with a handful software only".
>
> I assume that's the base for the request to have an overall repository.
> Researcher and students and private persons are allowed to not care.
No. They are not allowed "to not care". Such a repository would just be
a service, not more. I really don't know, what you want to tell me here.
> Licenses often contain exceptions for these users allowing free usage
> for 'non-profit, non-commercial, education, research, ...'.
And we are also not allowed "to not care". So such exceptions must be
handled carefully too. It seems, you ease the complete process/issue too
much.
> With your answer I have the feeling you proof the prejudice of users
> "debian is from DDs for DDs and professional sysadmins ignoring the
> common user or the user who is faced with the admin when looking into a
> mirror".
This is childish.
> That's the summary I hear between the lines when talking with others and
> reading different kinds of Linux related journals.
The question was: What is an appropriate section model for such a
repository. And this also heavily depends on what the repository will be
used for. If it will be used for sponsor search too, the
main/contrib/non-free approach is a further help for sponsors and DDs -
and in this case, the users are of course not part of these groups. So
if you see the sponsors/package maintainers view as "proof of prejudice
of users", this sounds very childish in my ears.
> > > As scientist I can put the most into main.
> >
> > No. That is completely wrong. What can go into main, is clearly written
> > in the policy.
> >
>
> I think you mix pieces of different puzzles here.
No, but maybe you do. I was talking about Debian's main/contrib/non-free
section model. So when you say, you could put everything into main, this
heavily sounds like a misunderstanding of what is allowed to go into
main. And ...
> For new 'devian-science.org' there is no policy established.
... it would IMHO make absolutely no sense to use a
main/contrib/non-free model with a completely different policy to
Debian. This sounds very silly. So I did not thought, that you could
mean such an approach or understand my statements in this way.
> I understand this
> thread to find one. You are talking about the debian policy for
> complete releases. It has the word 'debian' but also shall include at
> least ubuntu and maybe others based on debian initially.
Ubuntu uses a different section model. And because there cannot be a
mixed repository for Debian and Ubuntu, both can still choose a
different section model for their repository. Further we are here in
debian-science, not ubuntu-science, so we mainly talk about Debian. When
Ubuntu is going to have a different approach, they can tell and reason.
> > > 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.
> >
> > This is IMHO the job of debtags, and not the job of the repository. And
> > creating a "high level classification" directory structure, will make it
> > more complicated, to find a package (see, how many entries you must put
> > into a single sources.list to get an overview, what packages are
> > available). I disagree to such a model.
> >
>
> Yes, profit from 'debtags' I also suggested somewhere in this thread.
> To get more specific, something similar to
> http://alioth.debian.org/softwaremap/trove_list.php
> would fit. It list projects by classification.
> Looking at alioth, I wonder why you refuse a classification system
> because of too complicated.
Do you know anything, about the repository structure of a Debian
repository? Maybe you should first inform (this is really the feeling I
get, when I read your mails). I disagree to a differentiated section
model because of the already mentioned reasons. If you really mean the
directory structure (but then you probably misunderstood Kevin B.
McCarty), you maybe propose a potato-like structure. But this one has
several disadvantages against the pooled ones and we would have to
create new sub-sections, which are not allowed by the Debian policy, and
this is also not a good thing.
> Also, someone in this thread already suggested alioth as host candidate.
Alioth could be a candidate to host packaging projects. The Alioth
project will not host the repository.
> There seems only a lttle bit of fine classification necessary as there
> is only 'Science' bit no sub classes of science for special purpose SW.
There are many approaches to sub-class science. But the more sections
you create, the more entries are necessary for a sources.list and the
more difficult the package search becomes. And this leads to a
contra-productive effect, so it becomes harder to find the right package
(or even to get the overview, which packages are offered).
Regards, Daniel
Reply to: