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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
