-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mar 1, 2007, at 10:20 PM, Jean-François Mertens wrote: > > On 27 Feb 2007, at 18:44, Daniel Johnson wrote: > >> I don't know exactly why it's happening, but I have figured out some >> things. The "file changed as we read it" warning does occur sometimes >> with tar 1.15.1, but it always returned an exit code of 0 in such >> cases. It would return 1 if a fatal error occurred. Starting with >> 1.16, tar now returns 0 for success, 1 for non-fatal errors (like the >> file changed one) and 2 for fatal errors. The problem is that dpkg- >> deb fails if tar returns a non-zero exit code. Now dpkg-deb could be >> patched, but since you'd still want it to fail for truly fatal errors >> and the fatal error code changed from 1 to 2, it needs to know which >> version of tar it's using or Bad Things could happen. > Daniel, > > For the moment, the major problem seems to be in 10.4/unstable, > where we know the version of tar. > So why don't you go ahead and commit your patch to dpkg there _ > (with if you want a versioned dep on tar). > I've no idea about the bootstrap process (just know it is not starting > with just symlinks in %p pointing to corresponding things in /usr, > and then building in strict build-order with '%i' silently substituted > by '%p' until dpkg is installed). > But I can't see how such a patch _ sorry: much better, correction _ > of dpkg in that tree could have any negative impact, even on the > bootstrap process (and even if it was as I would have thought). > So please commit your correction to dpkg, unless someone > screams with good arguments in the next couple of hours ... > >> Another bit of information is that the code in tar that checks if a >> "file changed as we read it" changed after 1.15.1. Previously, the >> warning occurred if a file's ctime changed during archiving; now it >> will also occur if the file's size increases. I don't know why either >> of these situations is happening though. > I too would have by far preferred to understand this before; but > 'unstable' is not 'experimental', and we shouldn't hold up a fix > that's anyway needed _ for consistency between the 2 pkgs _, > just in order to pursue an experiment... > (I would bet rather on the ctime than on the size _ which looks > to me as an almost redundant test _, but evidence for that > will disappear after your patch .. (sigh) ) Well since I'm not a core developer, I don't think it would be appropriate for me to patch core packages. :) What I recommend for now is this: perl -pi -e 's,"tar","/usr/bin/tar",g' dpkg-deb/build.c That will force dpkg-deb to use the system's tar instead of fink's and would have the least side effects. Patching around the new tar's behavior would require significant changes to dpkg's logic. The function "checksubprocerr" is ultimately responsible for checking the exit code of subprocesses and it's designed to simply check for zero or non-zero status. There's no easy way to make it know that it needs to handle tar's exit code differently than for other processes. Another possibility, suggested by Dave Morrison, is a wrapper script for tar, which would massage the exit code into something dpkg-deb can handle, depending on the version of tar installed. Or tar can be epoched. Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD4DBQFF562l4sDFGYouOqARAsL1AJikmjsmlG3iBR5UvaaEwDqW0miWAJ91ZyS5 nueiaMGV60nRWKupfqoC7A== =7q4W -----END PGP SIGNATURE----- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
