Am Donnerstag, 20. August 2009 18:10:46 schrieb Andreas Gruenbacher:
On Thursday 20 August 2009 17:08:01 Adrian Schröter
Am Donnerstag, 20. August 2009 14:51:08 schrieb
I agree. Migrating packages with several levels
of source links becomes
somewhat complex, but the existing git frontend already requires all
this functionality; there is little left to do other than pushing the
resulting git repository to the backend. This should give us good
confidence that the conversion works well.
And I would like to see first how you intend to do the permission
checking (for write permissions as we have it now and for upcomming read
Maybe by checking permissions the same way as the build checks permissions
itself right now? The code for doing that hasn't been implemented yet
though; in fact, git support in the backend so far only exists in the form
of ideas unfortunately.
So your plan is to proxy the git operations through the api ?
(The permission checking code in the build service
which is currently done
in the frontend might end up getting moved to the backend soon for other
reasons, which might make a little more sense for a git backend as well.)
Dunno if it will get moved (not for 100% I am quite sure), but we will get
support also in the backend, yes.
together to the feature that our current server is storing
files (esp. the large tar balls) once, even when another user creates the
same package with same tar ball at a different place and with different
Without an idea for a solution here I see no way to move away from it.
It is easy to share the same object store among several git repositories
(this is where git stores things like files (blobs) and directories
(trees), which allows to set things up exactly as they are set up in the
build service right now. Git can also pack its object stores, which
shrinks them further.
Yes, but when you share these objects, can you avoid that some of them do not
become visible ?
PS: /me do not like the idea either to disallow reading files, but it seems to
be needed for non-opensuse.org
instances and maybe even for opensuse.org
for handling secret security updates later.
SUSE Linux Products GmbH
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org