Mailinglist Archive: opensuse-buildservice (261 mails)

< Previous Next >
[opensuse-buildservice] spec file wizard - how to proceed?
  • From: Michal Marek <mmarek@xxxxxxx>
  • Date: Wed, 18 Jun 2008 16:24:35 +0200
  • Message-id: <48591AA3.1060304@xxxxxxx>

as you probably noticed, the buildservice web interface now has a wizard
that helps with writing spec files. Yesterday, I improved it to generate
better spec files for perl and python modules (not yet on build.o.o) and
I hot already advice on how to add support for apache modules and ruby
gems ;-). Of course I'd like the wizard to be able to package as many
kinds of packages as possible, but I see some problems I'd like to solve
somehow before adding more features:

Problem #1 (more theoretical than practical): the main part of the
wizard is implemented in the frontend (aka API), the webclient only
translates xml to html forms and vice versa. The reason for this is that
I'd like to add a wizard interface also to osc one day. The problem is
that so far, the frontend has been just a simple proxy to the backend,
with access control, without any fancy functionality. Now the wizard
adds potentially buggy code that doesn't necessarily need to be there
(it would be easily implemented as a standalone application talking to
the frontend). The only reason for having the wizard on the frontend is
to be able to use it from different clients easily.

Problem #2 (practical): To implement good heuristics, the wizard at
least needs to look into the source tarball (if not run some
commands...). Here comes the problem: 'tar tf foo-1.1.tar.bz2' can take
a *lot* of cpu time, so where to perform such expensive actions?
a) on the frontend - can be abused for DoS easily
b) let the client send the filelist along with the tarball - makes the
client implementation too complicated, plus moves the DoS problem
from the frontend to the webclient
c) on the backend, dispatching the jobs to workers - would also allow
for more dangerous analysis of the package, but would impose
additional delays
d) create a separate wizard service and do all the job there - would
also solve problem #1, but would make the client implementation a bit
more difficult (need to talk to two different servers)
e) [insert great idea here]?

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

< Previous Next >
Follow Ups