Adrian Schröter wrote:

But having only project would have several dis advatanges:

* All needs to use same project setup config, means building for the same base distributions and using same package project config.

* write access to that project needs to be either more strict and less open than atm, or if you keep it open, no one can really trust this repo and you should not add it. Keep in mind that such a repo would be a perfect target for someone who wants to steal your credit cards numbers for example, what would be really easy than (no, I will not describe how;).

* several projects do conflict even at build time. We had the problem in the past that submissions to the old "supplementary" to fix A destroed B. (It was really hard for me sometimes to keep KDE working in that and often enough even more low level stuff like apache got crashed but other peoples submissions. And at that time only less than 10 people have commited to that. Imagine what happens with write access to more than 100 people)

* More people with write access will keep the project building, that means in worst case it will get never get released to the ftp server.

* 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. Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;) Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 2008-01-24 12:16:18 +0100, Henne Vogelsang wrote:

On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:

...

Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)

Get a buildservice account, link everything you want to your home, be done with it?

err no? this is plain stupid. first of all you would/should use aggregate. anyway just duplicating packages to avoid signing up multiple repositories is plain stupid. it waste build time, space on mirrors. imho it is much better to have small repositories focused on single package groups to avoid cross dependencies. packman is a bad example there. if you just want mediacodecs you get updated versions of tons of other libs. and sometimes they even broken other programs with it (libxml2 updates breaking kde's meinproc in the past).

That process has to be improved but in theory its very simple.

yeah. it is simple just subscribe the small repositories you really need. the most simple way might be one click installer. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Hi, On Thursday, January 24, 2008 at 13:37:48, Adrian Schröter wrote:

On Thursday 24 January 2008 12:16:18 wrote Henne Vogelsang:

...

On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:

...

...

Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)

Get a buildservice account, link everything you want to your home, be done with it?

HELLO ????

Hey there. How is it hanging? :) I dont know where you have been the last 4 years but static content like we have now is outmoded. You have to provide the building blocks, the means and the user (or a group of users) does the rest. Not necessarily in the buildservice frontend we have now, i tend to agree with you on that, but thats what these requests are about.

package managers are designed to handle multiple repos. If they do not do well, fix it or use a different package manager.

There should be no difference by having the same data in one or more repos for the package manager.

Im sorry but you are (still) designing the OBS for packagemanagers instead of people :) Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Hi, On Thursday, January 24, 2008 at 14:17:18, Adrian Schröter wrote:

On Thursday 24 January 2008 14:06:40 wrote Henne Vogelsang:

...

On Thursday, January 24, 2008 at 13:37:48, Adrian Schröter wrote:

...

On Thursday 24 January 2008 12:16:18 wrote Henne Vogelsang:

...

On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:

...

Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)

Get a buildservice account, link everything you want to your home, be done with it?

HELLO ????

Hey there. How is it hanging? :)

I dont know where you have been the last 4 years but static content like we have now is outmoded. You have to provide the building blocks, the means and the user (or a group of users) does the rest.

Not necessarily in the buildservice frontend we have now, i tend to agree with you on that, but thats what these requests are about.

You are aware that you suggested to duplicate several 100 of Gigabytes on our main server and all it's mirrors, because one single person wants a different repo setup ?

You are aware that you need to provide the means to do that right? Maybe in a way that it does not have the consequences you describe above...

Can you calculate, how much space we and all our mirrors would need to fullfill this request when every second of our openSUSE users will do this ?

Nope. But i can see other (web)services that provide content that is far more space intensive, to way more users then we do, without a problem. So it cant be that hard dont you think? :)

...

...

package managers are designed to handle multiple repos. If they do not do well, fix it or use a different package manager.

There should be no difference by having the same data in one or more repos for the package manager.

Im sorry but you are (still) designing the OBS for packagemanagers instead of people :)

I simply refuse to implement workarounds in OBS, just because no one fixes packagemanagers or design them for users.

You cant make the task of package installations (== what a package manager does) _much_ easier as it is right now. I think we can all agree on that. What you can make easier is providing the packages the user wants. A huge repository with thousands of packages is not the answer. A thousand repositories, with one package in each, aren't either. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

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. 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. * in Java:jpackage-1.7 we have about 200+ packages and many of them don't have their build dependencies yet. In that case is necessary to have a specialized repository, because the jpackage project is really big and there are a few peoples, which commits the packages. Regards Michal Vyskocil --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

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

...

...

On 25-01-2008 at 09:59, Dirk Stoecker wrote: On Thu, 24 Jan 2008, Adrian Schröter wrote:

...

However, when you have suggestions like, put project A and B and C together to D, we should really discuss and consider it here. Because I agree

Hello, that we

can

...

reduce the number of projects.

Ok. Some suggestions for cleanup.

a) Move contents of "net-snmp" into "network:utilities".

b) Move "filesharing" into "network:" tree.

c) Move contents of "Subversion" into "devel:tools".

d) Move "ggz" into "games:" tree

e) Move "editors" into "devel:" tree.

Looks like some sane suggestions... editors -> devel appears a bit strange... but I can't see a better point neither and it's very few packages there. Why is Apache for example an own Top-Level project? I would suppose it in server:http (as a subproject or whatever) Apache serves little other than http server. ASCIIParadize is mainly games... maybe games: (there are 2 games... could not identify what the hird package is). By name it sounds like a space invaders ;) Banshee -> Multimedia GPhoto -> Graphics In general I think the 'one product' projects should not exist at TopLevel. Dominique --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Fri, 25 Jan 2008, Adrian Schröter wrote:

Beside that, several of the suggestion are just moves. Btw, we can do the moves and add a rule to our redirector to avoid that users need to re-add the repos. However, I would like to get rid of these rules in the long run again.

Well, that's why doing a bit of cleanup now. The later it is done, the more trouble it will be.

...

In general I think the 'one product' projects should not exist at TopLevel.

Might be a valid rule ..

That was the idea behind my 3 tree-move suggestions :-) Another point: What is done with inactive home directories? There are some homes, which have partial stuff never finished, which keep the search results confusing. Can't there be something like "1/2 year no login" -> disable (with mail notice), "1 year no login" -> kill? Ciao -- http://www.dstoecker.eu/ (PGP key available)