On pátek 25 leden 2008, Michal Vyskocil wrote:
On Thursday 24 January 2008 12:03:00 wrote:
* With one large repo, it's 'either all or nothing' for the end user. E.g. imagine a web developer who wants the latest LAMP stack, but wants KDE to stay as is, so that his non-techie girlfriend doesn't get scared each time she uses the computer. I'd say the current setup suits him better in this case.
This is a misinterpretation of my post. I'm talking about the packages, which are not in openSUSE (for example gle-graphics.org, or the Squeak Smalltalk). Not about latest versions of KDE, or a LAMP.
I think that we are mixing these 2 things: 1. provide packages that are not in the base distro 2. provide newer versions of packages in the base distro
The BuildService provides a repositories like OpenSUSE_10.3 and a community repo should countain only packages based on libraries or tools included in this repos *only*. If any package needs the newest version of gcc, KDE, or something else, there's also a Factory repository (Debian users often use a mixed system and libzypp should brings a support for repository priorities like apt, or yum, which avoids to break the system). As Adrian saids, the Packman guys often tends to duplicate a packages from openSUSE, which should breaks the distribution and its bad.
I'm talking about the policy, that a creation of a specialized repo is exception, not a rule. I'm understand, that a big projects, like KDE, Gnome, Java*, or Apache needs the specific repository, because they are much more complex and its hard to maintain them. But there are already a part of a OpenSUSE (or will be in a future) and not be interested for the community repo. I believe, that most of simple end-user applications should be included in one repository, without a big problems.
Specialized repos are ideal for case 2 - for users that want to be on the bleeding edge in just one area and want to have stable distro otherwise. Even one-package top-level project is OK from this point of view. For case 1 we could have a project called like "Addon" with carefully selected stable packages that does not conflict with the packages in main distro. It should have limited number of maintainers who would review submissions of others. Links or aggregates to specialized projects probably can't be used because this project should typically get only well tested versions. Popular packages from this project would be good candidates for inclusion in next version of base distro. Vladimir Nadvornik --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org