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 <prais...@redhat.com> 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
