On 05 Mar 2007, at 02:30, David R. Morrison wrote:
> My interpretation of the early test results reported here is that tar
> is indeed detecting a change in ctime and nothing more serious.
> There are two possible solutions to this: patch tar, or patch dpkg.
> I'm going to advocate that we patch dpkg.
>
> My reasoning goes like this: the decision to have tar report an error
> condition for non-fatal errors, and to report it with a different
> exit code than for fatal errors, was a deliberate one by the tar
> maintainer. We may disagree with that decision, but the fact is, a
> version of tar has been released in which this change was
> implemented, and there is no reason to believe that the tar developer
> would reverse the decision if asked. For example, a related issue
> was raised on the bug-tar list three years ago, and received the
> answer "we are doing the conservative thing and won't change". See
> http://lists.gnu.org/archive/html/bug-tar/2004-03/msg00010.html .
>
> A request for a separation of exit codes is: http://lists.gnu.org/
> archive/html/bug-tar/2005-01/msg00053.html . Another relevant
> message which explains why the error code was changed for the non-
> fatal situation is: http://lists.gnu.org/archive/html/bug-tar/2006-10/
> msg00021.html . A comment about implementation is found here: http://
> lists.gnu.org/archive/html/bug-tar/2006-10/msg00024.html .
I fully agree with all the above. That was in fact my reason for
stopping encouraging d.j. to go ahead with his patch: my understanding
from his previous msgs was that he had a patch for dpkg to adapt
to the new interpretation of return codes by tar, but his reply seemed
to imply he would patch dpkg just to use /usr/bin/tar _ whith which I
wouldn't
agree, since that would just keep us stuck with a fixed old version
of tar,
until the postponed problem had to be faced again.
>
> Anyway, my conclusion from all of this is that the two-exit-code
> status of tar is here to stay, at least for now.
Except that in the thread mentioned by dmacks, it is mentioned that
a new version of tar was due yesterday (sorry _ had no time to check,
really have for personal reasons no time for at least a week except
for the most urgent things), with new meanings of return codes.
So the 2 should be synchronised _ updating to the last tar, and
adapting dpkg.
> And while Apple is
> currently using tar-1.15.x, we have no control over when they might
> change to tar-1.16.x. Thus, switching to /usr/bin/tar surrenders any
> control we might have over the problem, and patching tar itself dooms
> us to continue patching tar forever.
>
Sorry, should have put my above comment below this ...
> This is why I advocate patching dpkg so that when calling tar, it
> checks the exit code and only dies if tar had a fatal error. Of
> course, we'll need to make the new dpkg package depend on the new tar
> package, but this should not be a problem. (Note that dpkg-
> bootstrap, on the other hand, should rely on /usr/bin/tar and should
> *not* get this change.)en
[Or even below this ... :) ]
I would remain sorry not to understand the cause of the ctime changes;
but of course we can't take take "unstable" as an experimental setup.
But since the inconvenience of the present setup is so minor, even
for those where it fails _ it should suffice to re-run (cut-and-
paste) the
dpkg-deb command that failed _ , I would like to ask those who have
ever
experienced the problem to insert a sync right after "^sub
phase_build {$"
in %p/lib/perl5/PkgVersion.pm", and re-run their tests...
Indeed, my experience, corroborated by that of a number of sys-admins
on dozens of different machines, is that 10.4 on UFS is completely
broken;
_but that many troubles can be repaired by inserting an appropriate sync
(especially after creating a number of symlinks). Of course, since
then my
build-dirs are on (Case-sensitive) HFS+ partitions ...
But I've no evidence that sync'ing ids the only source .
I've seen no evidence that any of the above mentioned happened on UFS,
indeed none of those "bug reports" mentioned anything about underlying
system and hardware, but just on the off-hand chance that there might be
something wrong in the system itself about sync'ing, I would really
like this
experiment.
At least then, we would know for sure whether or not it is some
other process
(i.e., not related to fink...) that changes those ctimes.
And since there remains some time between adjusting tar to its latest
version
and then adjusting dpkg to take account of its latest exit codes, we
might still
find out ...
JF Mertens
-------------------------------------------------------------------------
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
