Mailinglist Archive: opensuse-buildservice (284 mails)

< Previous Next >
Re: [opensuse-buildservice] Reorganize repositories ?
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Mon, 29 Oct 2007 09:19:38 +0100
  • Message-id: <4725979A.8020801@xxxxxxxxx>
Hash: SHA1

Adrian Schröter wrote:
On Wednesday 17 October 2007 18:53:41 wrote Pascal Bleser:
One task that is notably missing is the reorganization of the repositories.
Right now it's seriously starting to become a mess, I'm afraid :\
Note that it also means discussing and finding guidelines about a few
things, most notably: repositories and packages by desktop environment
(KDE:*, GNOME:*) or by task (client:messaging, multimedia:photo) ?
Or some here and some there, as it is now ? (which is quite suboptimal IMO)

Please keep in mind that the organisation of the projects depends on the
wanted build enviroment. Packages/versions which can be reused in the build
enviroment or not. Additionaly it does also define the group of people with
write access to it.

Not sure the build environment is really a criterion in the current
grouping of packages into projects as of now, at least not for most of
them. I mean, one of the real questions in terms of organization of the
projects and packages is whether to group by "desktop environment" or by
"purpose" -- e.g. put kftpgrabber into "KDE:something" or in
"filesharing" ?.
The build environment is hardly a reason to put kftpgrabber into
KDE:Community, as it's pretty much the same target build repositories
everywhere (openSUSE_10.3, openSUSE_Factory, etc...), with the notable
exception of the repos with the latest Apache (e.g. for Subversion).

To me, the choice of where to host a package like kftpgrabber (or
kbackup or keep, could be in Archiving:Backup as well) is arbitrary and
non-deterministic as of now.

Is the user who wants to add access to packages asking for "a file
transfer client for KDE" or "a file transfer client" ?

Of course, we could also have them aggregated into both. Just that it
means more files to rsync for the mirrors.
Except if pure repository metadata aggregation is feasible and can be

And write access, dunno. Is it really important that a person has access
to server:foo but not to client:foo ? Are some categories more
"critical" than others wrt that ? Hardly.

It is NOT intended to setup the projects in a away to make it easier to find
packages, this needs to be done via different techniques like the
software.o.o/search interface.

It definitely needs to be done then, because currently it's quite
difficult for a somewhat less experienced user to find his way into the
tangle (dare I say "mess" ;)) of existing repositories.

But the Build Service roadmap contains half of the items on the Software
Portal roadmap anyway so I guess it will be implemented at some point.
Why work together one someone else's ideas, right.

As an example, gimp is in GNOME:STABLE, gqview is in multimedia:photo;
konversation is in KDE:KDE3, irssi in server:messaging.
Oh, yeah, and that's one of my pet peeves (Marcus knows about it ;)):
there are some obvious repositories/categories that are missing:
- client:messaging
- client:mail
- client:ftp
- system:utilities
(or move *:irc/* into *:messaging ? merge filesharing and client:ftp as
filetransfer ? etc...)

hm, maybe all client:* projects can be put into one ? Hm they have
already ;)

Why put them into one ? Then we can drop most of the subcategories for
server:* as well, it's exactly the same situation.
As said, it's arbitrary and target repository grouping has nothing to do
with the vast majority of the packages as far as I can see, as most are
just built against the standard repositories.

So what's the substance of your reply, keep it as is ?

- --
-o) Pascal Bleser
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE -

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >