On 2006-09-20 21:46:03 +0200, Andreas Jellinghaus wrote:
as a real newby I have lots of questions, maybe you can answer some of these?
a) on the web page - why no add all for adding all distributions? would simplify it for most users
this would be stupid. as any other project repository can be a build target. it might be useful to add a button "common base distros" which might add all suse distros + mandriva + fedora + debian + ubuntu. maybe more fine grained like: 'add all suse distros' 'add all debian based distros' 'add all fedora distros' something along that line.
d) is there a code name based selection system for building packages? e.g. it would be nice if I could upload *.diff.gz.sarge *.diff.gz.dapper *.diff.gz.etch and *.diff.gz.edgy with slightly different content for debian sarge/etch and ubuntu dapper and edgy. same again for rpm based distributions - while it might be a nice long term project to look in depth what distributions does what changes and why and how to merge them, as short term project it might be much nicer to edit the spec files, upload a new version of a package and get rebuilds without much work.
i am still not sure whether this is a good idea or not. atm i would say ... not a good idea. as the build service is not meant for that branching packages into distributions. i will think a bit more about it. stay tuned. :) (disclaimer my oppinion is not authoritive.)
e) versioning updates: is there any automatic in place that will update the versions e.g. in spec files and debian changelog files? if I upload mysoft 0.a.b+1, would I need to edit all spec files and diff.gz to manualy enter the new version or does some automatic this for me? same with revisions, if dsc files or something is changed.
oscupstream might be used for that. in general the idea is to have a upstream integration. so you can just trigger a version update and it will grab the new tarball or even a checkout from a SCM and update everything. this is pretty easy for rpm spec files. but for debian this gets a bit trouble some. the package changelog is normal part of the patch that adds the debian/ subdir. so it would be a -> unpack -> apply patch -> fix changelog -> rediff -> cleanup cycle needed. but we will see what comes out of the changelog integration feature here. to be discussed.
f) debian builds: debian has this habbit of renaming mypackage-0.a.b.tar.gz to mypackage_0.a.b.orig.tar.gz. do I need to upload the same file under both names, or will you take care of this with a symlink or rename for debian builds?
yes. you need to upload both tarballs.
g) If I want to jointly develop packages with a group of people, we need a non home: repository, right? and I need to ask here for approval before creating one?
you can add those users to your home project too. the home project is a project like any other in that regard.
h) if I guesses correctly at g) I'd like to have either "smartcard:" or "opensc-project:" or "opensc:" for opensc, openct, libp11, engine_pkcs11, pam-p11, pam_pkcs11, gtkcard, pcsc-lite, libccid, opensc-java and friends
security:smartcards would be my idea. so we can put other smartcard related projects there too.
i) opensuse buildservice is restricted to open source software as far as I know. what about java addons, are they ok? specifically, if java forces the author to sign them and to keep the signature key private?
at opensc-project we have a new project "opensc-java" which is a java crypto service (with smart cards via opensc as backend), and we needed to go through all the hassle of signing it etc. so while the source code is open source, it won't work with java unless signed. so our "build" process would be more like uploading the binaries and only moving files into place (or building from source, but the result wouldn't work at all, as we need to keep the signing key private).
as it is a good old habit of java to ship all kind of jar files intree. you could just ship the jar file as source and than just package it into opensc-java. as it should basically work everywhere right? or does the java part have JNI stuff? 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