Bug#136110: md5sum binary should be from textutils, not dpkg
On Wed, 6 Mar 2002, Jor-el wrote:
> On Tue, 5 Mar 2002, Glenn McGrath wrote:
>
> > On Wed, 27 Feb 2002 17:24:57 -0500
> > "Andres Salomon" <dilinger@voxel.net> wrote:
> >
> >
> > There is also a c library providing md5, one from libwww0 (packaged) and
> > another unpackaged libmd5 project
> > (ftp://ftp.cs.wisc.edu/ghost/packages/md5.tar.gz).
> >
> > Ive been thinking for a while that md5 is generally usefull enough to be a
> > seperate package, even though its small its still good to reuse code.
> >
> > If dpkg wanted to use the unpackaged libmd5 i would be prepared to package
> > it.
> >
> Glenn,
>
> I think 'dpkg' is an example of the case where code reuse of the
> nature you mention is not necessarily a good thing. Adding additional
> build dependancies for dpkg is not a good thing if one considers the
> porting to a new OS / architecture problem. I am in the middle of a port
> to AIX and have found out that some sgml packages have to be available
> first to build dpkg docs. Which I cant install as a deb unless I first
> complete the port of dpkg. In general, I think the less chicken and egg
> type problems there are with dpkg the better.
The md5sum code in dpkg is implemented as part of libdpkg. This allows the
md5sum binary to include it(statically), along with the dpkg binary
itself(again, statically).
We(dpkg developers) try to limit the build-time and run-time dependencies of
the dpkg system(within reason). Having a program that is not part of dpkg
itself get called by dpkg is a problem just waiting to happen.
Somewhat recently, dpkg stopped calling external gzip for this very issue, and
install links with a static version of zlib.
Reply to: