Hi Antonio, some final comments from my site :). I don't want to beat anyone.. and you are right, the code change would be a little bit larger than my initial patch - and I can wait for complains that the change is tooo big.. Simply, it makes sense to work on this only if the upstream is really interested — and in that case, I would be glad to continue.
> > Exit value 2 is a general warning exit status among compressors > > Then those compressors have a serious problem with their APIs that > should be fixed, or at least carefully documented. Callers like tar do > not mind if there were warnings or not, only if the data was succesfully > compressed or not. Yes, ..no!, warning means that data was successfully compressed, or not? Saying that the API has a serious problems is the only think you can do with (and it can be also considered rather like a matter of taste). Do you plan somehow to change the future and fix the compressors APIs? > >>if important programs like GNU tar begin accepting an exit status of '2' > >>as success for those compressors, it will prevent them from switching to > >>the correct and sane API > > > > This is not so truth, nobody prevents anyone from switching > > Suppose that gzip-1.6 begins returning '2' to mean fatal error, just as > most compressors are already doing (see below). This would work fine > with the current tar. But if '-z' is modified to accept '2' as success, > then the new tar with gzip-1.6 would produce truncated archives without > a warning. This is far worse than giving an spurious error. Therefore, > if tar is modified, gzip won't. That will be the time when GNU tar settings must be switched for gzip like s/--compress-program/--filter-program/ which will be basically one-liner. Where do you see the problem? This is also usual work of distro maintainer - configure its utility to cooperate correctly with other utilities. Thats also why I'm in this discussion (because the cooperation of utilities is not 100% OK atm). > > This patch is intended just to make tar work *now* .. don't wait forever. > > Passing -f to compress and considering all warnings from gzip as errors > is the simplest and safest way of making tar work now without > compromising the future. Nope, as far as you can not guarantee that it does not silence other errors. And no - we are compromising present NOW! ;-) and if we deal here with your way, we will probably forever. But it is just my opion. > > And even if some standard compressor change its API (I see this as an > > highly unlikely), it is very easily configurable on target distribution > > tar (distro maintainers can know, which API its distributed compressor > > uses) - not possible now, thats why I am trying to solve this. > > If tar is modified and later some compressor changes its API, user's > scripts will break and chaos will develop as soon as a partial update is > made. This is exactly the reason why is see the API change as unlikely. Do you really think that users are using 'gzip' *only* through a tar? If you make a change in gzip API ~> chaos will come. Pavel
