On Thu, 2010-06-03 at 12:51:18 +0200, Martin Pitt wrote: > Guillem Jover [2010-06-02 20:43 +0200]: > > Hmm, while testing and fixing few things here and there I got a bit > > absorbed and ended up touching most of the patch. So I've just taken > > it over (mainly given the amount of changes I've made to it). I've > > added a Signed-off-by line on your behalf, please tell me if that's > > fine with you.
> Of course, thanks a lot for cleaning it up! Perfect then, thanks, if eveyrthing else is fine, it's good to go, I'll be applying it later today. > > It might be a bit confusing as “dpkg -L pkg” will list all files even > > if not in the file system, but that's equivalent to the admin removing > > those after the fact, so I think it's fine. It will also allow in the > > future to ask dpkg which files are missing for example. > > Hm, did that behaviour change in your patch then? With mine, the .list > file that dpkg writes after unpack does not contain the skipped files, > and the test suite patch that I sent also verifies that (it calls dpkg > -L to check for present/absent files). Oh, didn't remember to run your test cases, will do so, and adapt it if needed too. And yes the behaviour changed on purpose, it's the only way dpkg can keep track of those files. It could get somehow smarted in the future once dpkg keeps track of file metadata. > > And yes, ideally this would get fixed in the future to be more > > precise, the problem is that I can only think about one way to do > > that, with a two pass algo over the tarball. > > Either that, or installing a file would create its directory instead > of relying on it being created previously. Would you see anything > wrong with that? Yes, it would not preserve the permissions and ownership from the directory from the tarball. thanks, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
