Hi, Marcelo E. Magallon wrote:
> somewhere I read that a reimplementation of mksplit.pl in C was > needed in order to remove a dependency of dpkg on Perl, but I > can't find the reference anymore. I could only find approx one reference for this goal [1]. Luckily, even if that doesn’t pan out, there are plenty of other benefits to well written C code. Most importantly, it makes code sharing a little easier. I guess this would also make repairing a broken perl installation a little simpler on some system with only access to small media, though I haven’t encountered a need for dpkg-split in a long while. Thanks for working on it. > Oddly enough I don't see a > dependency of dpkg on perl either $ apt-cache show perl-base | grep Essential Essential: yes > I did compare the output with the Perl > version in several test cases and it's identical. Some test cases (or methods for producing them) would make me very happy. dpkg doesn’t have enough automated tests of basic functionality. Automake provides a rudimentary test harness [2]. > Subject: [PATCH] Reimplement mksplit in C > > My original intention was to do without some of the pipes, but for the > initial implementation this is just a translation of the original Perl > program into C, without much in the way of optimization. It produces > the same output and exits in the same way as the original program (mod > exit status probably). I will let the dpkg-split experts comment on the important part. > --- a/dpkg-split/Makefile.am > +++ b/dpkg-split/Makefile.am > @@ -9,7 +9,7 @@ AM_CPPFLAGS = \ > -I$(top_srcdir)/lib > > > -bin_PROGRAMS = dpkg-split > +bin_PROGRAMS = dpkg-split mksplit I think this should be bin_PROGRAMS = dpkg-split pkglib_PROGRAMS = mksplit so that mksplit stays in /usr/lib/dpkg. Hmm? Jonathan -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100403061933.ga23...@progeny.tock
