[Clam-devel] Re: RFS: CLAM, C++ library for audio and music

[David García Garzón]

The ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493282
Packages: http://clam.iua.upf.edu/download/linux-debian-sid/svnsnapshots

I did some fixes on the packages following your advices and lintian's. I will 
do some extra effort on christmas holidays to wrap it up so i will be glad if 
you can do another review on the current status of the packages so you can 
find more problems i could fix.

My todo list looks like this (+done -todo):
+ Not a native package anymore (adding a diff to upstream)
+ examples should be packaged with dh_examples.
+ debian/changelog has an incorrect distribution
+ Not tarballing the doxygen documentation
+ Remove CFLAGS and  INSTALL_PROGRAM from debian/rules
+ Remove alternative dependency on old libxerces28-dev
- Fill independent RFP's for applications and plugins.																		
- Vcs-* fields is for Debian packaging, not upstream VCS repository
- Include non GPLv2-or-later licenses in debian/copyright
- Add man pages to the extra binaries (needed?)
- Sign DSC files.

Some questions:
- Should i remove the Vcs fields while there is no public svn of the diff?
- Could you point me to an example of debian packaging repository? Just to 
know how that should be organized.
- Are the man pages for the extra binaries needed at all to be in the package? 
Those files are not meant to be launched by user but by the core programs.

David.


On Divendres 05 Setembre 2008 22:22:29 Vincent Bernat wrote:
> OoO La nuit  ayant déjà recouvert d'encre ce jour  du jeudi 04 septembre
>
> 2008, vers 23:26, David García Garzón <dgarcia at iua.upf.edu> 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.

-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia