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. 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. 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. 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 ... -- Micka�l Scherer
