Mailed to mentors, we like to do stuff in public and I don't claim to be infallible, either. ;-) On Tue, May 30, 2006 at 02:09:49AM +0200, Vedran Fura? wrote: > Kari Pahula wrote: > > As far as the technical side of packaging goes, it seems to be mostly > > in a good shape. One thing you should see about is not compiling > > statically the included libraries (boost and libjs, at least) but > > using the shared libraries in Debian already. It would save space on > > users' systems and is a good practice securitywise. > > > > Try to make a patch to send to upstream about this change. I'm sure > > they wouldn't mind having optional configure switches to not build the > > included libraries and using the ones present on a system. It would > > save your workload in the long run, too. > > I mailed him, here is his response: > > "That can be done, and I am willing to do it if debian/ubuntu teams > insist on it, but this solution has its problems: I was thinking of a configure option to not compile the included libraries but to use the ones present on the system already and leave as the default behaviour what bfilter's build system currently does. > 1. Nobody wants an extra dependency, especially when it's bigger than > the package itself. We have apt, which can easily fetch any dependencies. This argument really applies to people who compile software from source. A valid concern for an upstream, which is why I would be happy to leave as the default behaviour what their build system currently does. > 2. When I ship boost (actually just a fraction of it) as part of > bfilter, I can be sure that the version I ship doesn't have bugs (at > least visible ones). It was more than once when I had to apply a patch > after reporting a bug upstream and getting either "Fixed, here is a > patch" or "Already fixed in CVS" responses. Also, sometimes they > introduce new bugs, so I can't be sure that the next boost release > doesn't break bfilter. That goes the other way around too. Any security bugs that are found in boost or other statically linked libraries will remain unfixed until bfilter itself is recompiled. The boost packages in Debian are patched independently of upstream, so the fixed-in-CVS issue is less so around here. > 3. You are not going to save memory by linking to a dynamic library, > because: > a) There are few programs that use boost, so sharing memory is unlikely. > b) Most of boost is template code, which ends up in the executable > anyway." The security issues are really more important than the memory or disk usage savings. > Should I insist? No. There are few issues that really require insisting anything in maintaining packages, and this one isn't one of them. Licensing issues can require changes from the upstream, as well as SONAME hygiene with libraries. Most things can be done in diff.gz (or with patch system of your choice) and if they patch is in a nice enough shape to send to upstream, then it is a good practice to do so. Try to see if you could get bfilter patched yourself to use Debian's libjs and boost but if it looks like it would lead to too much madness then just leave it as is. Be mindful that doing so would lead to more source code that you'd be responsible mostly yourself to fix when and if it breaks. > > You need to list all copyright holders and the years involved, even > > for the libraries included in the upstream source tarball. See > > http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html > > > > I see that the debian/copyright file might get quite long in this > > case. However, it is necessary. That'll make FTP masters happy and > > you don't want to make them unhappy. And no, repackaging the > > .orig.tar.gz file to remove those libraries just to avoid having to > > list their copyrights is not the way to go, either. > > You mean something like this: > $ grep -rih copyright bfilter-1.0.2/ | sort -ufi > ...is the right way? Yes, quite long. I'd do something like this: Copyright 1234 Author (License of bfilter itself) bfilter includes libfoo Copyright 5678 Author of libfoo (License of libfoo) bfilter includes libbar Copyright 0010 Author of libbar (License of libbar) etc.
Attachment:
signature.asc
Description: Digital signature