On Sat, Jan 16, 2010 at 10:40:56AM +1300, Paul Wise wrote: > On Sat, Jan 16, 2010 at 2:55 AM, Justin Azoff <JAzoff@uamail.albany.edu> wrote: > > > I am looking for a sponsor for my package "bro". > ... > > That said, I would like some feedback on how I am building the package now, > > specifically if the debian/rules and debian/control files look sane. > > Usually one uses RFC instead of RFS in the subject when one is just > looking for comments. My mistake :-) > Comments on the source package: > > I'd strongly suggest using a rules.tiny style rules file and the > override_dh_* rules instead if you are going to use dh. I had tried that, but it wasn't working. I realize now that is because I am using the older debhelper in lenny. I will install the debhelper backport or setup a squeeze VM and rewrite the rules file. > python-subnettree is already available in Debian, there is no need to > turn the embedded code copy into a package. Please ask upstream to > remove the embedded code copy. Same for capstats, trace-summary and > any other embedded code copies that I missed. It definitely isn't a > good idea to be adding to this file, which is already huge and scary > enough as is: > > http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies I don't know how I missed that python-subnettree already existed! I will build separate source packages for: * capstats * trace-summary * python-broccoli Does this sound like a good plan? I will ask upstream about removing the extra copies. > > Remove all the .ex files, README.Debian. Will do. > libbroccoli3 will mostly be installed automatically, so it should have > a much less detailed package description than the -dev package. Will do. I will go through a bunch of existing libfoo and libfoo-dev packages for ideas. > Installing /etc/broccoli.conf in libbroccoli3 isn't a good idea. > Debian Policy 8.2 says this: > > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-support-files > > "If your package contains files whose names do not change with each > change in the library shared object version, you must not put them in > the shared library package. Otherwise, several versions of the shared > library cannot be installed at the same time without filename clashes, > making upgrades and transitions unnecessarily difficult." > > I imagine /etc/broccoli.conf will not change when libbroccoli3 changes > to libbroccoli4. You should rename it to /etc/broccoli3.conf, install > it into a separate package or remove it entirely. Please co-ordinate > with upstream here. I will make a new package called libbroccoli-common. Alternatively, I don't believe that file is required for normal operation. If not, could I just install it as a package example file? > Please repost your RFC when the package is much closer to being ready > for the archive. I will. Thanks for looking things over for me! -- -- Justin Azoff -- Security & Network Performance Analyst
Attachment:
signature.asc
Description: Digital signature