Re: Reimplement mksplit.pl in C
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
Re: Reimplement mksplit.pl in C
Jonathan Nieder jrnie...@gmail.com writes: 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]. Given that a fair bit of dpkg is written in Perl, which means that people are already familiar with the Perl test harness, you may want to consider using my C TAP Harness framework for writing tests instead. http://www.eyrie.org/~eagle/software/c-tap-harness/ It implements a pure C version of Perl's Test::Harness and prove (which is useful because prove isn't entirely happy with tests not written in Perl), but probably more relevantly, it provides TAP libraries for writing tests in C and shell. The Automake test harness is okay, but I really like the Perl test framework output and its test protocol. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871vexm4lp@windlord.stanford.edu
Re: Reimplement mksplit.pl in C
Russ Allbery wrote: Jonathan Nieder jrnie...@gmail.com writes: Automake provides a rudimentary test harness [2]. Given that a fair bit of dpkg is written in Perl, which means that people are already familiar with the Perl test harness, you may want to consider using my C TAP Harness framework for writing tests instead. http://www.eyrie.org/~eagle/software/c-tap-harness/ Looks neat. Thanks for pointing me to it. Cheers, Jonathan My last message was missing some footnotes. Oops. [1] http://lists.debian.org/debian-devel/2001/03/msg00250.html http://lists.debian.org/debian-embedded/2009/04/msg00064.html [2] http://www.gnu.org/software/hello/manual/automake/Simple-Tests.html -- 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/20100403065849.ga23...@progeny.tock
Re: Reimplement mksplit.pl in C
On Sat, Apr 03, 2010 at 01:19:33AM -0500, Jonathan Nieder wrote: I could only find approx one reference for this goal [1]. Ah, yes, that was it, thanks! Removing Perl from the essential set. While going to bed, I actually figured that was the reason why I wasn't finding perl in the dependencies, but I didn't remember this was the reason I had read about for the reimplementation. 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. Sure. I'd like to take this implementation and factor out whatever is reusable. There are a couple of maybe-useful gimmicks in there, for example the Perl idiom `program` transliterated into C. I cheated and took a guess regarding how large should a buffer be to be large enough for this use case: my guess is one page. There are other hard-coded buffer length limits, too. Memory concious it ain't right now, this code. 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. Same here. The last time I used dpkg-split for something was back in ... 1996? 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]. I was thinking about that. The problem with mksplit is that the generated files contain an embedded timestamp, so when I say identical I actually mean identical modulo the embedded timestamp. I mean, you can't just cmp two sets of files. Beyond that, mksplit has several bits of code identifiable as functions that ought to be separated and those could have unit tests. I would have to look in more detail at dpkg-split to see if it's possible to devise a good automated test for this functionality. The two cases I can think of are splitting an archive that splits to a single piece, splitting to multiple pieces and some failure cases. There's a check in mksplit.pl (also implemented in mksplit.c) that I'm still trying to figure out how to trigger (the corresponding error message refers to the header being too large). I think this should be bin_PROGRAMS = dpkg-split pkglib_PROGRAMS = mksplit so that mksplit stays in /usr/lib/dpkg. Ah, right, thanks, updated patch attached. Marcelo From acbd7b59d0d48ec47191d67846029aedc3c49afe Mon Sep 17 00:00:00 2001 From: Marcelo E. Magallon marcelo.magal...@gmail.com Date: Fri, 2 Apr 2010 22:27:50 -0600 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). The reimplementation can use some refactoring love. --- dpkg-split/Makefile.am | 12 ++- dpkg-split/mksplit.c | 279 2 files changed, 288 insertions(+), 3 deletions(-) create mode 100644 dpkg-split/mksplit.c diff --git a/dpkg-split/Makefile.am b/dpkg-split/Makefile.am index 6f6043c..3ea9d00 100644 --- a/dpkg-split/Makefile.am +++ b/dpkg-split/Makefile.am @@ -24,10 +24,16 @@ dpkg_split_LDADD = \ ../lib/compat/libcompat.a \ $(LIBINTL) +mksplit_SOURCES = \ + mksplit.c -pkglib_SCRIPTS = mksplit -EXTRA_DIST = mksplit.pl -CLEANFILES = $(pkglib_SCRIPTS) +mksplit_LDADD = \ + ../lib/dpkg/libdpkg.a \ + ../lib/compat/libcompat.a \ + $(LIBINTL) + +pkglib_PROGRAMS = mksplit +CLEANFILES = $(pkglib_PROGRAMS) do_perl_subst = $(AM_V_GEN) sed -e s:^\#![:space:]*/usr/bin/perl:\#!$(PERL): diff --git a/dpkg-split/mksplit.c b/dpkg-split/mksplit.c new file mode 100644 index 000..5ca34d6 --- /dev/null +++ b/dpkg-split/mksplit.c @@ -0,0 +1,279 @@ +/* This program is only supposed to be called by dpkg-split. + * Its arguments are: + * sourcefile partsize prefix totalsize partsizeallow msdostruncyesno + * Stdin is also redirected from the source archive by dpkg-split. + * + * Copyright © 1995 Ian Jackson i...@chiark.greenend.org.uk + * Copyright © 2010 Marcelo E. Magallon mmaga...@debian.org + * + * This is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You
Re: Reimplement mksplit.pl in C
On Sat, 03 Apr 2010, Jonathan Nieder wrote: 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]. The more recent reference is in http://wiki.debian.org/Teams/Dpkg/RoadMap Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100403192354.ga17...@rivendell
Bug#576338: [dpkg] --purge not well described in manual page dpkg.1
Package: dpkg Version: 1.15.5.6 Severity: minor Hi, man dpkg contains: -r, --remove, -P, --purge package...|-a|--pending Remove an installed package. -r or --remove remove everything except conffiles. This may avoid having to reconfigure the package if it is reinstalled later. (Conffiles are configuration files that are listed in the DEBIAN/conffiles con- trol file). -P or --purge removes everything, including conffiles. That's only partly correct. In contrast to apt-get purge, dpkg is also able to purge already removed packages. This is not well described in the manual page (Remove an installed package.). I suggest to remove installed or to rewrite it to something as Remove an (maybe partly) installed package. Jens -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
