Re: [Bug-tar] Software Proposal

[Charlie Sale]

To clarify about the paxutils shared library: should I abandon the project for tar? Should I talk to paxutils instead and work with them? Should I keep going on that's API?

Regarding paxutils lack of shared library: could I modify pads build system to create a shared library with all source files? I do think that simply compiling their source into a shared library with tar would be a bad idea because updates would go poorly, if even possible.

I would definitely NOT use an API based on exec and system because that make a garbage API that wouldn't work properly if at all. 

Here is my working concept of how the API would be developed for tar (if I do it). Please tell me if you think it will work out of I should go back to the drawing board:

* There would be a data structure called 'tar_t' that would contain pointers to most of the global variables declared in 'common.h' along with a few other data members. This would be used for making tar objects that would set the global variables used in the project. 

* All tar_t structures are initiated with a function that calls some of the tar internal functions that initiate the system

* A function would take a tar_t object as a parameter. With this object, I would use macros to set the global variable, and then call the corresponding internal tar function.

This is a very rough draft and it will be revised, but for know I think it's a start. I am still figuring out how the internals work, so please tell me if I have any glaring issues with the implementation. 

As for building the library, I would compile the tar source against a possible paxutils library and gnulib (if it has a shared library). I would also have to install some of the tar headers.

Please let me know what you think. 

Thanks

Charlie Sale

On Mon, Sep 25, 2017, 4:06 AM Pavel Raiskup <address@hidden> wrote:

On Saturday, September 23, 2017 4:14:54 PM CEST Charlie Sale wrote:
> My though was to develop a C API that would be part of the GNU tar package.

I believe something like this was planned to happen in paxutils [1], from
the README file of that project:

  | GNU paxutils aims to provide:
  |
  |   1. tar implementation, replacing current GNU tar,
  |   2. cpio implementation, replacing current GNU cpio,
  |   3. pax implementation, conforming to POSIX standard.
  |
  | All three implementations will be built around a common (presumably
  | shared) library.

So, I would suggest you to start there, and Sergey probably has some more
info.  Shared library would be invaluable, same as '/bin/pax'
implementation in GNU (yeah, cpio/tar are LEGACY utilities when you have a
look at POSIX specs..).

The problem is that most of the work is nowadays done in GNU tar only,
without paying too much attention to merge the stuff back to paxutils
project;  so I guess a lot of manpower is needed to get this work done.

> It would handle tasks that would be completed via the command line
> option.  My thinking is that it would convenient to have a built-in API
> instead of having to find outside dependencies.

This sounds like you plan to implement work-around to the fact that paxlib
has no shared lib;  so I would much rather see this implemented properly.
API built on top of execve('/bin/tar' ..) would be brittle, with a bit
unexpected output..

Pavel

--

~Charlie Sale