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
The original source had README and README.new file with same contents That is fixed now. New source rpm at the same place.
Absorbed the prep section in the code, new spec and srpm at the same place.
Added README.new to the rpm now. spec and srpm at the same place.
Absorbed ugly autoconf in the source now :)
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.
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 :)
(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.
(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.
(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.
(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.
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.
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
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.
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
(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.
@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.
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.
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.
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)
(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
> - 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.
Are there any actual ABI changes which would warrant going to .so.2?
(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 :)
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.
(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.
(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
> 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.
(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.
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.
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.
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
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?
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.
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
Any progress here?
No response after many months; I'll just close this out.
(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.
Then submit your own review request for it. This review is stalled because the submitter is not responding and, according to policy, is closed.