jeudi 18 décembre 2003

Paxutils status

From a letter to Richard Stallman and Sergey Poznyakoff, in reply to Sergey who is trying to sort out the status of the tar and Paxutils projects.

It has been a good while since I worked on Paxutils matters. All my ideas on the matter, including the overall plans on which we agreed, are documented (so far that I remember) within all administrative files and folders I transmitted to Paul Eggert, together with all Paxutils source in their latest work state, which did hold extensive changes since the latest Paxutils pretest.

As a way to cut on all the confusion created by the parallel releases of tar by Paul while Paxutils was being pretested, and to fully resist the temptation of ever interfering with Paul's later decisions and works about Paxutils (I do not act with others in ways I would not like myself), I deleted everything related to Paxutils on my side, once Paul told me he fully secured all the stock I sent him. So, I do not have anything concrete left of Paxutils, besides my fading memory of the project.

This is only later, when I progressively realised that Paul was not to fulfil his repeated promises about unifying histar with Paxutils that I became sad about all the work that was being ignored and lost. I felt especially bad for all those users who I told that their contributions were accepted and integrated for the next release of Paxutils. I never ever intended to lie to them.

About tar, cpio and Paxutils as separate projects, a bit of history might help at sorting things. John Oleynick maintained cpio for a good while, and the transmission of cpio from John to Tom Tromey has been a long, but successful adventure. At the time, Tom and I were working at the design of Automake (after an idea from David Mackenzie) and were intimately collaborating, and we considered with great pleasure the idea of merging tar and cpio together. We added a newly rewritten pax on the way, and chose Paxutils as a neutral name between tar and cpio. (We also considered other versions of cpio, tar and pax ― all our notes should be in the administrative files).

The cpio in Paxutils was really the most up-to-date, and was reworked for better integration with the rest, putting code in common, uniformising style, etc. Restarting from the latest cpio distribution would clearly be a backward step, I do not think there is anything to gain there.

tar itself has a more complex story. Paul started from an old pretest of Paxutils, modified it heavily on his side on many aspects, implementing huge file support an a very Solarishly way (on which I was not much agreeing, should I say). He then submitted me a single, really big patch. It was all-mixed, intervowen, unsorted. He probably expected me to apply it whole, while I wanted to consider each topic of the patch separately, and told him it would take a good amount of time to study and process it all. Paul asked me if I would object that he publishes tar with his patch, separately, for people in urgent need of using LFS. That was OK with me. Then, Paul started not only to maintain his patch, but also reimplement in his tar things that were already solved in the tar distributed within later Paxutils, and differently. He went as far as removing from his tar amounts of code I wrote in view of large file support on legacy systems. My code was not aligned along Sun Solaris methods, which Paul venerates, but my code was meant to be more widely portable. In my views, Paul challenged and dismissed my maintenance works, so much that I thought preferable to resign than impose our fight to the community.

What it means in practice is that the current tar has been forked from an old pretest of Paxutils, and so, a merging of both would be useful, given you can get a hold on Paxutils. I'm sure that Paul made good works that we cannot ignore (Paul is technically competent, there is no doubt about this). I also think that Paxutils has good code and changes to recycle. Merging, if ever, is going to require courageous work, fairly tedious and unrewarding. In my opinion, many months of work need to be identified and redone. Paul despisingly told that for him, two or three days would suffice, but apparently never found those few days. In the meantime, Paul acted as if whatever users do not resubmit directly to him, was not worth anyway.

Repairing POSIX support in tar is the main long term goal that tar may have. I guess that the step-wise plan for Paxutils, which was accepted by the FSF, has been fully abandoned or forgotten with the change of maintainer. But any plan that has some chance to work is good, in my opinion. star is also especially interesting in that it uses efficient techniques for streaming tapes, which techniques could be recycled for most or all Paxutils tools.

All this being said, Sergey, I can only wish you good courage, and collaboration from all involved people. I cannot provide much myself, besides bits of historical background, which may not be that useful in practice, once you will have found all the files you need. On the other hand, do not hesitate writing to me if you think that some discussion might help, yet while I did my best while being there, you understand I have no responsibility anymore around tar or Paxutils.

1 commentaires:

  1. The Paxutils project is now maintained by Sergey Poznyakoff. See `paxutils - GNU Project - Free Software Foundation (FSF)` http://www.gnu.org/software/paxutils/.

    Some old sources for this project are also available from `pinard/paxutils - GitHub` https://github.com/pinard/paxutils — merely select the tag corresponding to the version you want, and ask for download. This became possible after Sergey got from Paul Eggert, on 2004-03, a copy of all administrative files I (François Pinard) transmitted to Paul on 1999-07, when Paul officially took over tar and Paxutils responsibilities.

    RépondreSupprimer