On Sun, 7 Sep 2003, Michael Scherer wrote: > On Sunday 07 September 2003 03:37, Vincent Danen wrote: > > > So, by your point above, we should have one of everything in main? > > Well, where's my better implementation of gkrellm-plugins (in > > contribs). Oh, well, just for kicks, let's throw a few others out > > there. Where's my alternative to zssh or zope or xscorch or > > webalizer/analog or uudeview or seahorse... ad naseum. What makes > > uucp better than any of these programs that don't have a "better > > alternative" in main? > > we should first think what does having a package in main implies : > > Package in main are on cds. This is important, because it means that > they can be installed without internet connection. > This also means that some packages, like uucp, who are mostly used with > a internet connection, could be moved to contribs without too many > problems.
Hmm, do you know that uucp is about the only solution for mail transfer *without* an internet connection? It is possible to run uucp over tcp/ip, but if we take uucp out of main, it means that users who only have a dialup uucp will have a big problem installing it. Granted, this is becoming quite rare, but the entire Western Cape Schools email network runs uucp, and in a number of schools, requiring an ISP subscription could mean the decision between using email and not ... Vince's solution was to have uucp in CS instead, but how many schools in the Western Cape do you think would be able to afford that? People will just install a BSD (which AFAIK still has some limitations regarding authentication etc relating to nss/pam) or Windows (since the school board has uucp for Windows, and instructions on the painful use of Mercury Mail on Windows) instead. Maybe we should remove ppp or fetchmail instead ;-). Anyway, IMHO, uucp is a more feature-critical package than a log analyzer (if you need one, you *must* be connected to the internet, you can always run your log analysis later once you have installed it). > Packages on cds are more visible. But this is a problem of contribs > visibility, and it should be solved by making more publicity for > contribs, and having urpmi.setup on cd. It also needs a menu entry ... > Packages on cds can be installed automatically by drakX. It can still > work with a tweaked install cd, thanks to MakeCD, but not everybody > know this possibility. Having the capacity to script install is > importatn for professionnal, i guess. > > Packages in main are updated for security, and contribs are not. This is > bad, since, to give a example, some packages like apache2 modules are > in main, and others are in contribs. But, on mdk9.1, apache was > updated, and only main packages got rebuild. We should have a way to > propose some update for contribs, even non official ones. I know that > security team is quite over booked, but contributors could handle the > problem. At least, it is better than nothing. > > So, based on this difference, we should think about what should be in > main, and what should go in contribs. Well, we need a wider audience than just us. Something like popularity_contest would be a way to see which packages in main are effectively obsolete (or need other justification to stay in). > We should strive to reduce the difference between contrib and main. This > would stop some of the endless discussion on what in main and what in > contribs. > We can even dream of a distribution where there is no difference > between main and contribs ... Well, this would require easy access to contrib for the average user ... most of whom currently only know Mandrake as 3 download CDs. BTW, regarding what roles Mandrake is used in, the poll on MandrakeClub shows 50% use Mandrake on the desktop, 50% use Mandrake on the desktop and server, which that server use *is* very popular (imagine the chaos if 50% of Windows users used Windows on servers). Regards, Buchan -- |----------------Registered Linux User #182071-----------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ***************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *****************************************************************
