On Sat, 2005-12-24 at 19:08 +0200, Simo Kauppi wrote: > The changes to the man pages came from accidentaly running lintian -I > instead of lintian -i. I use these lines in my ~/.devscripts so I always get the correct lintian/linda stuff. export DEBUILD_LINDA=yes export DEBUILD_LINTIAN_OPTS=-i export DEBUILD_LINDA_OPTS=-i > > * debian/rules: > > * CFLAGS should include -g -Wall > > I thought it is enough that -Wall -g comes from the configure script > when called with --enable-warnings --enable-debug. Do I need to add > those flags to the debian/rules "just in case". --enable-warnings sounds like it could be the same, but for --enable-debug it could have other effects, like plastering annoying "DEBUG BUILD" messages all over the place. > > * debian/watch: delete or (preferably) fix it > > I'm not sure if this file is generally used. I could probably remove it, > but just for the future reference, how would one fix it? Removing the > commented lines, or...? Russ pointed out how this is used. I should also point out dehs (Debian External Health Status): http://dehs.alioth.debian.org/ > > * debian/links: any reason you disable the linking in > > swfs/Makefile.in and use debian/links instead? > > The linking from the Makefile.in linked to /home/myhome/projects/..., > which didn't feel good (eventhough it worked when installed). Building > in two different machines gave two debs, which where different in that > respect. So, it seemed like a good solution :) I see, sounds like a bug in the upstream build system. Personally, I prefer to work around bad stuff that upstream does in debian/rules - in your case I would have removed upstreams links just after make install. > > * I'm confused as to why you would use --disable-lame and also > > patch the build system. Also, wouldn't it be better to just let > > the build system detect LAME and use it if possible? This way > > users can easily rebuild the package with LAME support if they > > wish. > > Disabling in both places is probably an overkill. The problem was > actually with the avi2swf and wav2swf which compiled without the lame, > but did not work. So, I wanted to make sure that the build doesn't > produce any non-working binaries. Ah, fair enough. I would hope that upstream's configure process would detect if LAME is available and only build those binaries when it is available. > > * Also, I'm confused as to why you disable installing the header > > and library. > > Because they didn't have any documentation and I wasn't sure if they can > be used without the lame support. I was going to add them later. Ok, fair enough. Uploading the binaries without the library until you get the library sorted out is a good idea. > Then again, I guess development libraries don't necessarily need any > documentation. So, I'll name it librfxswf-dev and the Python wrapper > python2.x-rfxswf (and come up with another name for the library/Python > wrapper w/lame). Sounds good. > Is the libdevel the correct section for a static library/header files? Yep, libdevel is the correct one. Generally, having static libraries (instead of shared libraries) in debian is considered bad for security reasons. There are exceptions for stuff like ffmpeg that changes it's API/ABI very frequently. Have a look at the libraries sections of the debian policy document: http://www.debian.org/doc/debian-policy/ > Sure, upstream seemed very happy about my intention to package it for > Debian. Excellent! > > * You might want to upload a version with LAME support to > > http://debian-unofficial.org > > OK, any suggestions about naming? swftools-nonfree, librfxswf-nonfree-dev and python2.x-rfxswf-nonfree? Those sound ok, or swftools-lame/etc. Be sure to make those conflict against the non-LAME ones if they contain the same files. I'd also suggest that the README.Debian mention how to get the LAME version. -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part