Bug 546169

Summary: Review Request: libtar-ng : tar library
Product: [Fedora] Fedora Reporter: Huzaifa S. Sidhpurwala <huzaifas>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, kdudka, kevin, lemenkov, notting, rc040203, sundaram, terjeros
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-14 14:44:14 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 201449    

Description Huzaifa S. Sidhpurwala 2009-12-10 04:40:39 EST
Spec URL: http://huzaifas.fedorapeople.org/spec/libtar-ng.spec
SRPM URL: http://huzaifas.fedorapeople.org/srpms/libtar-ng-1.2.11-1.fc12.src.rpm
Description: libtar-ng is a fork of the libtar library under the MIT license.

koji rawhide build : http://koji.fedoraproject.org/koji/taskinfo?taskID=1866790
Comment 1 Huzaifa S. Sidhpurwala 2009-12-10 22:33:51 EST
The original source had README and README.new file with same contents
That is fixed now.
New source rpm at the same place.
Comment 2 Huzaifa S. Sidhpurwala 2009-12-10 23:13:20 EST
Absorbed the prep section in the code, 
new spec and srpm at the same place.
Comment 3 Huzaifa S. Sidhpurwala 2009-12-10 23:39:11 EST
Added README.new to the rpm now.
spec and srpm at the same place.
Comment 4 Huzaifa S. Sidhpurwala 2009-12-11 00:15:01 EST
Absorbed ugly autoconf in the source now :)
Comment 5 Ralf Corsepius 2009-12-11 01:01:19 EST
What is the purpose of this package?
So far, your packages appears to be a private fork, to me. Is the upstream dead/non-responsive?

Furthermore, please increment the release tag each time you change your src.rpm. Otherwise it's hard to tell for reviewers, whether you modified your package.
Comment 6 Huzaifa S. Sidhpurwala 2009-12-11 01:07:56 EST
Upstream, does not have time to maintain this anymore.
There are patches lined up for months now sp the ones related to memory leak.

See:
https://lists.feep.net:8080/pipermail/libtar/2009-May/000259.html

I will bump the release next time :)
Comment 7 Ralf Corsepius 2009-12-11 01:25:04 EST
(In reply to comment #6)
> Upstream, does not have time to maintain this anymore.
OK, then my impression was right, it's a private fork.

> There are patches lined up for months now sp the ones related to memory leak.
Well, this is nothing unusual.

IMO, the appropriate approach to this would be to either "patch the original package" or to make your "private fork" a "public fork"/"official project".

Private forks don't help anybody - How do other distros handle this issue in this particular case?

> I will bump the release next time :)  
TIA.
Comment 8 Huzaifa S. Sidhpurwala 2009-12-11 01:29:11 EST
(In reply to comment #7)
> (In reply to comment #6)
> > Upstream, does not have time to maintain this anymore.
> OK, then my impression was right, it's a private fork.
> 
> > There are patches lined up for months now sp the ones related to memory leak.
> Well, this is nothing unusual.
> 
> IMO, the appropriate approach to this would be to either "patch the original
> package" or to make your "private fork" a "public fork"/"official project".
> 
This is not a private fork.
What makes a fork private or public?
I am ready for other people to contribute to this project too, its just that its hosted on fedorahosted which is easier for me then putting it on sourceforge.

> Private forks don't help anybody - How do other distros handle this issue in
> this particular case?
> 
> > I will bump the release next time :)  
> TIA.
Comment 9 Ralf Corsepius 2009-12-11 02:38:41 EST
(In reply to comment #8)

> This is not a private fork.
Your fork is your private pleasure.

Should it make it into Fedora, it is nothing but a Red Hat/Fedora proprietary fork, competing with other distros, other forks and the official upstream.

> What makes a fork private or public?
Launch an official project, with home-page, mailing list etc.

> I am ready for other people to contribute to this project too, its just that
> its hosted on fedorahosted which is easier for me then putting it on
> sourceforge.
There is nothing wrong with hosting a project on fedorahosted.
 
> > Private forks don't help anybody - How do other distros handle this issue in
> > this particular case?
It's a pity you didn't answer this - For now I advise reviewers not to approve this package.
Comment 10 Huzaifa S. Sidhpurwala 2009-12-11 02:59:30 EST
(In reply to comment #9)
> (In reply to comment #8)
> 
> > This is not a private fork.
> Your fork is your private pleasure.
>
What do you mean?
I decided to fork because i want to add features and upstream has no time.
 
> Should it make it into Fedora, it is nothing but a Red Hat/Fedora proprietary
> fork, competing with other distros, other forks and the official upstream.
> 
There is no official upstream now, he does not want to maintain, please read what i have said earlier.

> > What makes a fork private or public?
> Launch an official project, with home-page, mailing list etc.
Home page: https://fedorahosted.org/libtar-ng/
mailing list: https://fedorahosted.org/mailman/listinfo/libtar-ng-devel
Next time, investigate before you say something!
> 
> > I am ready for other people to contribute to this project too, its just that
> > its hosted on fedorahosted which is easier for me then putting it on
> > sourceforge.
> There is nothing wrong with hosting a project on fedorahosted.
> 
> > > Private forks don't help anybody - How do other distros handle this issue in
> > > this particular case?
> It's a pity you didn't answer this - For now I advise reviewers not to approve
> this package.  


I really have a feeling you are trying to be more of  a blocker than a contributor.
Comment 11 Huzaifa S. Sidhpurwala 2009-12-11 03:01:14 EST
I am not forking this because Red Hat needs it,
Working at Red Hat is my $DAYJOB, this is my contribution to Fedora,
both of these are completely different.
Comment 12 Terje Røsten 2009-12-11 05:08:39 EST
Please calm down. 

I guess Ralf means that is much more useful if you work with other users of libtar. That would typically mean other distro maintainers.

I see that e.g. Debian has several patches applied, here is the diffstat in 
lib/

 lib/Makefile.in            |   53 
 lib/extract.c              |    8 
 lib/output.c               |    5 
 lib/wrapper.c              |    1 
 libtar/Makefile.in         |   18 
 libtar/libtar.c            |    5

Please contact the libtar maintainer in Debian and see if you guys can merge 
your efforts, then create a new release that both Fedora and Debian can use.

When that is done, you can continue the package review (if needed, the libtar
pkg can might continue it's life with updated sources).

Debian info available here:

 http://packages.debian.org/squeeze/libtar
Comment 13 Michael Schwendt 2009-12-11 05:27:30 EST
1) See my reply to your thread on fedora-devel-list


2) Quoting from comment 10:

> Next time, investigate before you say something!

> I really have a feeling you are trying to be more of  a blocker
> than a contributor.  

:-/  Fix your attitude, please.


3) Package is not ready yet. It would be insane to approve it or what is offered at the libtar-ng project site. I consider myself another blocker as I see multiple issues:

* It conflicts with "libtar" not just all file names, but also in the SONAME.

* The src.rpm does not even attempt at trying to resolve the conflicts with libtar.

* Mind you, the original libtar maintainer has written he might want to return to maintaining _his_ libtar, but based on an already started albeit unfinished rewrite. This asks for further conflicts if you are serious about making your libtar-ng use a libtar ABI+API.

* Packaged tarball only adds a README.new in an ambiguous way as the COPYRIGHT and README files have not been touched (despite having received a fresh file timestamp). The new web page is not mentioned anywhere. Instead, references to old web pages are still found.

* Hints: Remove the superfluous autom4te.cache directory and their contents prior to packaging up the libtar-ng tarball. Cuts the tarball size in half.  Additionally, prefer bzip2 over gzip.
Comment 14 Michael Schwendt 2009-12-11 06:35:41 EST
Forwarding from my fedora-devel-list post, the license is more BSD (with no advertising clause) than MIT. The author backs up my impression as the comment on "MIT" prompted him to explicitly call his licensing "BSD-style":
https://lists.feep.net:8080/pipermail/libtar/2009-December/000282.html
Comment 15 Ralf Corsepius 2009-12-11 07:10:48 EST
(In reply to comment #10)

> > > > Private forks don't help anybody - How do other distros handle this issue in
> > > > this particular case?
> > It's a pity you didn't answer this - For now I advise reviewers not to approve
> > this package.  
> 
> 
> I really have a feeling you are trying to be more of  a blocker than a
> contributor.  

Do a reasonable job and I will not complain. - This case however, you went too far - I am expecting you to excuse.

Besides this:
* Basing works on private forks are a classical way inexperienced programmers outsmart themselves (c.f. "bundled API incompatible libs).
* Proposing to include them into Fedora is typical for new-comers, who are not aware about the issues they are causing.
* It would not be the first time somebody @RH was pushing a RH fork into Fedora, without coordination with upstream and/or other distros.
Comment 16 Rahul Sundaram 2009-12-11 14:08:36 EST
@Ralf, you continue to blur the lines between folks who work on Fedora as a full time job and people who are volunteers within Fedora and happen to work at Red Hat. You need to stop doing that.
Comment 17 Kevin Kofler 2009-12-13 18:10:08 EST
IMHO, this should be packaged, and in a way to Obsoletes/Provides: libtar as it's backwards-compatible and actually actively maintained unlike libtar. The Obsoletes/Provides should of course be versioned, so if a new libtar springs up at a later point (i.e. if the maintainer really goes back to actively developing it), it can be introduced instead of or in addition to the fork.
Comment 18 Huzaifa S. Sidhpurwala 2009-12-14 02:38:14 EST
Hi,
So taking into consideration all the feed back , here are the changes done:

- bump soname in the code from 1.2.11 to 1.2.12
- In the srpm, libtar-ng now obsoletes libtar, so that the conflicts are resolved.
- Tar ball is bz2 and not gzip to save space.
- The autom4te.cache dir is now removed.
- License changes from MIT to BSD as per the original suggestion of the author.
- Removed README.new from the tar and updated README with new code details,
  Also updated COPYRIGHT, while retaining the original clauses.

SPEC:
http://huzaifas.fedorapeople.org/spec/libtar-ng.spec

SRPM:
http://huzaifas.fedorapeople.org/srpms/libtar-ng-1.2.12-1.fc12.src.rpm

Any more comments/suggestions would be welcome.
Comment 19 Rahul Sundaram 2009-12-14 02:57:22 EST
Some suggestions not related to packaging guidelines:

* Post to http://lists.freedesktop.org/mailman/listinfo/distributions and contact other distribution maintainers. Check if other distributions have patches you can merge. 

* Specify a Roadmap in the wiki or a TODO in the source code on your plans forward

* I also recommend using LZMA compress archives (tar.xz)
Comment 20 Huzaifa S. Sidhpurwala 2009-12-14 03:27:25 EST
(In reply to comment #19)
> Some suggestions not related to packaging guidelines:
> 
> * Post to http://lists.freedesktop.org/mailman/listinfo/distributions and
> contact other distribution maintainers. Check if other distributions have
> patches you can merge. 
> 
done
> * Specify a Roadmap in the wiki or a TODO in the source code on your plans
> forward
> 
done. The README file already had it, but i added it to the project web page too.
> * I also recommend using LZMA compress archives (tar.xz)  
OK
Comment 21 Michael Schwendt 2009-12-14 04:02:05 EST
> - bump soname in the code from 1.2.11 to 1.2.12

Caution! You did NOT change the internal SONAME at all. It is still "libtar.so.1".
You also wrote "Bump the soname" in the README. Distribution packagers (but also developers and ordinary users) will run wild if you don't get the library versioning right.


* Please run "rpmlint -i" on the src.rpm and the built binary rpms. It prints some helpful warnings. (This is also in the Review Guidelines)

* "BuildRequires: libtool" is not needed for properly prepared source tarballs.

* To have the top source directory file name contain the %{version} would be good.
Comment 22 Kevin Kofler 2009-12-14 04:17:00 EST
Are there any actual ABI changes which would warrant going to .so.2?
Comment 23 Huzaifa S. Sidhpurwala 2009-12-14 04:20:43 EST
(In reply to comment #22)
> Are there any actual ABI changes which would warrant going to .so.2?  

There is no ABI change, hence the major soname is still .1 :)
Comment 24 Michael Schwendt 2009-12-14 04:25:13 EST
Wrong question, Kevin. ;)   An actual SONAME version change at this point would not only be unexpected, but nonsense as in case of an immediate ABI- (and perhaps also API-) incompatibility it would be more appropriate to use the "-ng" also in the SONAME.
Comment 25 Huzaifa S. Sidhpurwala 2009-12-14 04:38:15 EST
(In reply to comment #21)
> > - bump soname in the code from 1.2.11 to 1.2.12
> 
> Caution! You did NOT change the internal SONAME at all. It is still
> "libtar.so.1".
> You also wrote "Bump the soname" in the README. Distribution packagers (but
> also developers and ordinary users) will run wild if you don't get the library
> versioning right.
> 
> 
As said later, there is no ABI change yet, hence it was wrong for me to mention "soname bump" in README, removed that.
SRPM: http://huzaifas.fedorapeople.org/srpms/libtar-ng-1.2.12-2.fc12.src.rpm
SPEC: http://huzaifas.fedorapeople.org/spec/libtar-ng.spec

> * Please run "rpmlint -i" on the src.rpm and the built binary rpms. It prints
> some helpful warnings. (This is also in the Review Guidelines)
rpmlint is happy now
> 
> * "BuildRequires: libtool" is not needed for properly prepared source tarballs.
> 
Does that mean i have to include a copy of libtool in the source ball,
I saw a few libraries, but none of them really seem to do it.
Any idea?
> * To have the top source directory file name contain the %{version} would be
> good.
Comment 26 Huzaifa S. Sidhpurwala 2009-12-14 04:38:46 EST
(In reply to comment #21)
> > - bump soname in the code from 1.2.11 to 1.2.12
> 
> Caution! You did NOT change the internal SONAME at all. It is still
> "libtar.so.1".
> You also wrote "Bump the soname" in the README. Distribution packagers (but
> also developers and ordinary users) will run wild if you don't get the library
> versioning right.
> 
> 
As said later, there is no ABI change yet, hence it was wrong for me to mention "soname bump" in README, removed that.
SRPM: http://huzaifas.fedorapeople.org/srpms/libtar-ng-1.2.12-2.fc12.src.rpm
SPEC: http://huzaifas.fedorapeople.org/spec/libtar-ng.spec

> * Please run "rpmlint -i" on the src.rpm and the built binary rpms. It prints
> some helpful warnings. (This is also in the Review Guidelines)
rpmlint is happy now
> 
> * "BuildRequires: libtool" is not needed for properly prepared source tarballs.
> 
Does that mean i have to include a copy of libtool in the source ball,
I saw a few libraries, but none of them really seem to do it.
Any idea?
> * To have the top source directory file name contain the %{version} would be
> good.
Comment 27 Huzaifa S. Sidhpurwala 2009-12-14 04:39:43 EST
(In reply to comment #24)
> Wrong question, Kevin. ;)   An actual SONAME version change at this point would
> not only be unexpected, but nonsense as in case of an immediate ABI- (and
> perhaps also API-) incompatibility it would be more appropriate to use the
> "-ng" also in the SONAME.  

Do i really need to call the library as libtar-ng.so.X ?
Since its supposed to be currently compatible to libtar.so.X
Comment 28 Michael Schwendt 2009-12-14 05:05:55 EST
> As said later, there is no ABI change yet,

Do you know what the term SONAME refers to?

> Does that mean i have to include a copy of libtool in the source ball,

Yes, and you do so already.

> I saw a few libraries, but none of them really seem to do it.

Uh? Dozens if not hundreds of library projects, which produce shared libraries, use libtool (via autoconf/automake) and include it in their tarballs.

> Do i really need to call the library as libtar-ng.so.X ?

Well, see comment 13 and remember that the libtar author would prefer for forks not to use the libtar name. You've renamed the tarball name, but everything else still is in the libtar namespace. This will lead to complications if you ever (a) plan to really touch the SONAME, and even if (b) you plan to extend the API.
Comment 29 Huzaifa S. Sidhpurwala 2009-12-14 05:17:31 EST
(In reply to comment #28)
> > As said later, there is no ABI change yet,
> 
> Do you know what the term SONAME refers to?
> 
i do 
> > Does that mean i have to include a copy of libtool in the source ball,
> 
> Yes, and you do so already.
> 
> > I saw a few libraries, but none of them really seem to do it.
> 
> Uh? Dozens if not hundreds of library projects, which produce shared libraries,
> use libtool (via autoconf/automake) and include it in their tarballs.
> 
> > Do i really need to call the library as libtar-ng.so.X ?
> 
> Well, see comment 13 and remember that the libtar author would prefer for forks
> not to use the libtar name. You've renamed the tarball name, but everything
> else still is in the libtar namespace. This will lead to complications if you
> ever (a) plan to really touch the SONAME, and even if (b) you plan to extend
> the API.  


I agree, by above. I am going to rename the namespace to libtar-ng, and the libraries name would change too.
will submit new package soon.
Comment 30 Kevin Kofler 2009-12-14 10:15:45 EST
There's no requirement to include autotools-generated files in the upstream tarballs, it's perfectly possible to generate them at build time. Doing this generation at build time is just not the way the autotools are intended to be used by upstream. But it's done in quite a few cases and it has some advantages (but also drawbacks). That said, in this case, you aren't running libtool at build time, so it doesn't make sense to put it as BuildRequires.

My personal recommendation would be to convert the build system to CMake, which doesn't use that kind of generated files at all and is just generally nicer. But there's nothing wrong from a packaging standpoint with using autotools, be it at tarball generation time or at build time.
Comment 31 Kevin Kofler 2009-12-14 10:18:06 EST
Re renaming the .so library, the drawback is that doing that requires all the packages using it to be patched to use the new name and rebuilt. But it's true that it can prevent conflicts later on and that it does a better job of complying with the wishes of the original upstream.
Comment 32 Michael Schwendt 2009-12-14 13:00:15 EST
At least in Fedora, libtar is used by only a few packages:

$ repoquery --disablerepo='*' --enablerepo=rawhide-source --srpm --whatrequires libtar-devel
mfiler3-0:2.1.3-3.fc12.src
abrt-0:1.0.0-1.fc13.src
barry-0:0.15-0.9.20090630git.fc12.src
hydrogen-0:0.9.4-1.fc12.src

Double-checking:

$ repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires libtar.so.1
hydrogen-0:0.9.4-1.fc12.i686
mfiler3-0:2.1.3-3.fc12.i686
libtar-devel-0:1.2.11-15.fc13.i686
abrt-plugin-filetransfer-0:1.0.0-1.fc13.i686
barry-0:0.15-0.9.20090630git.fc12.i686
Comment 33 Huzaifa S. Sidhpurwala 2009-12-16 02:00:31 EST
The following changes have now been made:

1. Changed upstream code so that the soname actually changes from libtar.so to libtar-ng.so to avoid any conflicts in future.

2. Removed BR libtool from the spec.

However the bundled tool which contains an example implementation of the library is still called libtar,
Should i change that as well?

New SPEC: http://huzaifas.fedorapeople.org/spec/libtar-ng.spec
New SRPM: http://huzaifas.fedorapeople.org/srpms/libtar-ng-1.2.12-3.fc12.src.rpm

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1874549

Michael, Kevin,
Thanks for looking into this so far, Anything else i should do over here?
Comment 34 Huzaifa S. Sidhpurwala 2009-12-16 03:36:18 EST
Ok, i guess since i am changing libtar to libtar-ng i might do so for the bundled test app as well.
I have done the changes, new spec and srpm at the link given below.

http://huzaifas.fedorapeople.org/spec/libtar-ng.spec
http://huzaifas.fedorapeople.org/srpms/libtar-ng-1.2.12-5.fc12.src.rpm

Let me know if you want anything else done.

thanks.
Comment 35 Michael Schwendt 2010-01-26 15:05:19 EST
The renaming and creation of a fork has been half-hearted.

* Lots of manual pages still refer to <libtar.h> and duplicate filenames of the manual pages found in libtar-devel. Sooner or later there will be conflicts.

* Renamed manual pages refer to <libtar_ng.h> which doesn't match what is shipped: <libtar-ng.h>

* The package is hostile as long as it does:

Obsoletes:      libtar <= 1.2.11
Provides:       libtar = 1.2.12
Comment 36 Terje Røsten 2010-04-18 10:16:48 EDT
Any progress here?
Comment 37 Jason Tibbitts 2010-11-14 13:51:58 EST
No response after many months; I'll just close this out.
Comment 38 Kamil Dudka 2010-11-14 14:08:27 EST
(In reply to comment #37)
> No response after many months; I'll just close this out.

libtar-ng needs to be packaged.  There has been no update of libtar since 2003.
Comment 39 Jason Tibbitts 2010-11-14 14:44:14 EST
Then submit your own review request for it.  This review is stalled because the submitter is not responding and, according to policy, is closed.