OoO La nuit ayant déjà recouvert d'encre ce jour du jeudi 04 septembre 2008, vers 23:26, David García Garzón <[EMAIL PROTECTED]> disait :
>> Please, file an ITP for this package. This will be useful to track any >> progress, especially if someone has handled the upload or not. > I filled it before sending the RFS: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493282 OK. >> Moreover, the .dsc file is not signed. > Must the key be validated by any debian maintainer at all? This would be better but this is not mandatory. However, this should be your key. > As they are different source packages i don't know whether I should fill a > single ITP bug and RFS request or just one for each. It would be better. For example, clam could be uploaded soon while clam-XXX could have a lot of problems and its upload would be delayed for several months. This would be better to have its own ITP. >> At first glance, here are the problems with the current package: >> - debian/changelog has an incorrect distribution > I think that dhc has an --distribution option that could do the work. Or you can just edit by hand. ;-) > We are creating the dsc files from ubuntu and then generating all the > packages > for debian and ubuntu with pbuilder using that same dsc. The script we are > using, at clam/CLAM/scripts/doDebianPackages.py, is very convenient for us to > provide non-official debian and ubuntu packages. But maybe not the way to > proceed when officializing the procedure. Any suggestions are wellcome in > that sense. Everybody is free to generate packages as they want to. However, keep in mind that you need to write sensible changelog (the script will have some difficulties). As long as the script gives good results, this is fine to use it. >> - Vcs-* fields is for Debian packaging, not upstream VCS repository > Debian packaging is currently maintained at the upstream VCS. That is also > very convenient for us at the moment as we are doing fixes to the packaging > as we do changes on the install. But we really need advice as this seems also > to produce some inconveniences. Being debian maintained in the same > repository, are those fields ok? Should we keep a separate repository? Could > we just to store the diff of the debian a part and keep most of debian > folders in upstream svn? Both questions are related. Even if now, upstream and Debian packager are closely related, this may not be the case in the future. Debian packaging should only be targeted to go into Debian, not to be downloaded from the website, not to be included into Ubuntu (even if it will eventually migrate to Ubuntu when present in Debian). For example, in the packages that you propose to download from the website, you could widen the dependencies by depending on software not available any more or by suggesting softwares not available into Debian. Therefore, you need a dedicated branch or repository. >> - some of the files are licensed under MIT/X11, some are GPLv2 only > I guess they are included 3rd party files. Any suggestion on how to deal with > that? You just have to mention the files licensed under different licenses in debian/copyright. As long as the licenses are compatible, there is no problem. >> - examples should be packaged with dh_examples > Do you mean dh_installexamples? Yes. > Well i saw that qt4 package just ships a tarball. Is it that done by > dh_installexamples? Well i'll use dh_installexamples and see what i > get. Dunno. I think this is a bad idea to install examples as tar.gz. The user need to unpack them somewhere while he has explicitely asked for their installation. > Thanks for all the suggestions and fixes. We might need advice regarding how > to adapt our current release process to something more debian > friendly. Start with a fresh changelog, just for Debian. Try to apply the above suggestions and we will review the packages again. -- I NO LONGER WANT MY MTV I NO LONGER WANT MY MTV I NO LONGER WANT MY MTV -+- Bart Simpson on chalkboard in episode 3G02
pgpl5eF4WdfjP.pgp
Description: PGP signature
