Hi! On Mon, 2011-04-25 at 09:47:47 +0200, A Mennucc wrote: > Il 25/04/2011 07:28, Guillem Jover ha scritto: > > But my main problem right now is that I didn't find clear > > documentation of the “debdelta” file format, the closest thing that I > > found was the debpatch [1] example file in the debdelta package.
> (unfortunately the problem is that, from 2005 to ~two months ago, I > was the only one working on debdelta.. so the documentation is mostly > in my head...) Sure. I think just documenting the file format, and nothing else, would be enough to get a clear idea of how all this works, and at least for me how to try to integrate it, and where. It would not need to be too exhaustive though. > > Something that I found undesirable is that it seems to require executing > > a shell script included in the debdelta package to regenerate the data? > yes. Why would that be undesirable? Shell scripts are simple, well > known, and very powerful. (Indeed they are often used also for > "postinst" etc etc in deb packages...). Using shell scripts for > patches was a design decision in 2005 that I am quite happy of: it > enabled me to ameliorate the patches a lot in the following years, > without ever changing the delta internal format. While I can understand that it makes changing the format easier, and it was probably the right tool for fast prototyping, it also implies the file cannot be automatically inspected/verified/handled w/o implicitly trusting it. Which I don't think it's a good property for a file format. The case you mention about maintainer scripts is not equivalent, as they are only run on installation/etc, and not on say dpkg-deb extraction (say -I, -c, -f, etc), or when joining split packages with dpkg-split. > > Anyway I don't quite like the idea, it would imply > > offloading some of the dpkg unpacking logic out of dpkg, or just > > duplicating it inside dpkg itself to deal with unpacking from tar > > and from the file system itself and to rely safely on the file metadata > > from the binary package. > yes that second one would be my idea. Well, in all ways we think of it > , since there is an overlap we may want to eliminate, then either we > bring some logic of debdelta into dpkg, or some logic of dpkg into > debdelta... So, my first instinct would be to bring that logic into dpkg (or a new dpkg-debdelta or whatever), instead of offloading it, but as mentioned earlier I don't think I've enough understanding of how debdelta works internally to know how the integration could happen, or if that would be the best way to do it. thanks, guillem -- 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/20110506085932.ga1...@gaara.hadrons.org
