[ANN] Archive::Tar::Minitar 0.5.1

[Austin Ziegler]

I am pleased to announce the release of Archive::Tar::Minitar 0.5.1, a
bugfix release over Archive::Tar::Minitar 0.5.0. This is one of two
utility packages required for installation and use of Ruwiki as a
RubyGem.

For those who verify PGP signatures, note that I have changed to
signing my releases with GPG instead of PGP 8.

Archive::Tar::Minitar README
============================
Archive::Tar::Minitar is a pure-Ruby library and command-line utility that
provides the ability to deal with POSIX tar(1) archive files. The
implementation is based heavily on Mauricio Fernández's implementation in
rpa-base, but has been reorganised to promote reuse in other projects.

This release is version 0.5.1, offering a bugfix over version 0.5.0. The
library can only handle files and directories at this point. A future version
will be expanded to handle symbolic links and hard links in a portable manner.
The command line utility, minitar, can only create archives, extract from
archives, and list archive contents.

Using this library is easy. The simplest case is:

require 'zlib'
require 'archive/tar/minitar'
include Archive::Tar

# Packs everything that matches Find.find('tests')
File.open('test.tar', 'wb') { |tar| Minitar.pack('tests', tar) }
# Unpacks 'test.tar' to 'x', creating 'x' if necessary.
Minitar.unpack('test.tar', 'x')

A gzipped tar can be written with:

tgz = Zlib::GzipWriter.new(File.open('test.tgz', 'wb'))
# Warning: tgz will be closed!
Minitar.pack('tests', tgz)

tgz = Zlib::GzipReader.new(File.open('test.tgz', 'rb'))
# Warning: tgz will be closed!
Minitar.unpack(tgz, 'x')

As the case above shows, one need not write to a file. However, it will
sometimes require that one dive a little deeper into the API, as in the case
of StringIO objects. Note that I'm not providing a block with Minitar::Output,
as Minitar::Output#close automatically closes both the Output object and the
wrapped data stream object.

begin
sgz = Zlib::GzipWriter.new(StringIO.new(""))
tar = Output.new(sgz)
Find.find('tests') do |entry|
Minitar.pack_file(entry, tar)
end
ensure
# Closes both tar and sgz.
tar.close
end

Copyright
=========
# Copyright 2004 Mauricio Julio Fernández Pradier and Austin Ziegler
#
# This program is based on and incorporates parts of RPA:ackage from
# rpa-base (lib/rpa/package.rb and lib/rpa/util.rb) by Mauricio and has been
# adapted to be more generic by Austin.
#
# 'minitar' contains an adaptation of Ruby/ProgressBar by Satoru
# Takabayashi <[email protected]>, copyright © 2001 - 2004.
#
# This program is free software. It may be redistributed and/or modified
# under the terms of the GPL version 2 (or later) or Ruby's licence.
#
# $Id: README,v 1.2 2004/09/22 17:47:43 austin Exp $

 

[Mauricio Fernández]

I am pleased to announce the release of Archive::Tar::Minitar 0.5.1, a
bugfix release over Archive::Tar::Minitar 0.5.0. This is one of two
utility packages required for installation and use of Ruwiki as a
RubyGem.

I have just RPAfied it; while doing so, I found a problem in your
release process: the directories in the tarballs you provide are created with
wrong permissions (0555) and tar might not be able to create further
files/dirs inside:

archive-tar-minitar-0.5.1/archive-tar-minitar.gemspec
archive-tar-minitar-0.5.1/bin
archive-tar-minitar-0.5.1/ChangeLog
archive-tar-minitar-0.5.1/Install
archive-tar-minitar-0.5.1/install.rb
archive-tar-minitar-0.5.1/lib
archive-tar-minitar-0.5.1/Rakefile
archive-tar-minitar-0.5.1/README
archive-tar-minitar-0.5.1/tests
archive-tar-minitar-0.5.1/bin/minitar
tar: archive-tar-minitar-0.5.1/bin/minitar: Cannot open: Permission denied


This also affected your Diff::LCS release; in order to get the sources,
I had to edit the tarfiles manually.

This should fix it:

$ ldiff -u Rakefile.orig Rakefile
--- Rakefile.orig 2004-09-26 18:26:11 +0200
+++ Rakefile 2004-09-26 18:26:22 +0200

@@ -77,7 +77,7 @@
ddnew = dd.gsub(/^#{current}/, DISTDIR)
mtime = ReleaseDate || File.stat(dd).mtime
if File.directory?(dd)
- { :name => ddnew, :mode => 0555, :dir => true, :mtime => mtime }
+ { :name => ddnew, :mode => 0755, :dir => true, :mtime => mtime }
else
if dd =~ %r{bin/}
mode = 0755

 

[Austin Ziegler]

I have just RPAfied it; while doing so, I found a problem in your
release process: the directories in the tarballs you provide are created with
wrong permissions (0555) and tar might not be able to create further
files/dirs inside:

archive-tar-minitar-0.5.1/archive-tar-minitar.gemspec
archive-tar-minitar-0.5.1/bin
archive-tar-minitar-0.5.1/ChangeLog
archive-tar-minitar-0.5.1/Install
archive-tar-minitar-0.5.1/install.rb
archive-tar-minitar-0.5.1/lib
archive-tar-minitar-0.5.1/Rakefile
archive-tar-minitar-0.5.1/README
archive-tar-minitar-0.5.1/tests
archive-tar-minitar-0.5.1/bin/minitar
tar: archive-tar-minitar-0.5.1/bin/minitar: Cannot open: Permission denied

This also affected your Diff::LCS release; in order to get the sources,
I had to edit the tarfiles manually.

This should fix it:

Thank you, Mauricio. Question for people interested in packaging:
since this is merely a packaging error (not affecting ANY files in the
released code), should this update be a separate version or should it
be a replace-in--place? (It only affects .tar.gz files).

-austin

 

[Eivind Eklund]

Thank you, Mauricio. Question for people interested in packaging:
since this is merely a packaging error (not affecting ANY files in the
released code), should this update be a separate version or should it
be a replace-in--place? (It only affects .tar.gz files).

I am of the distinct opinion that ANY change to the release should
result in a bump. A number of the repackaging systems out there use
one way/secure hashes (SHA1, MD5 - do not use for new apps, et al) to
verify that the files involved in a release are the same as the ones
the person doing packaging saw. If you change the release in any way,
you'll invalidate this, and waste the time of the people that use
these systems, as they end up getting your modified tarballs and start
looking through diffs etc to see if you have been attacked and gotten
a trojan.

At least for FreeBSD ports, you'll get a fallback to our mirrors if
the file isn't there, so there is little problem with just removing a
wrong release.

So: New release numbering for ANY change.

Eivind.

 

[Austin Ziegler]

I am of the distinct opinion that ANY change to the release should
result in a bump. A number of the repackaging systems out there use
one way/secure hashes (SHA1, MD5 - do not use for new apps, et al) to
verify that the files involved in a release are the same as the ones
the person doing packaging saw. If you change the release in any way,
you'll invalidate this, and waste the time of the people that use
these systems, as they end up getting your modified tarballs and start
looking through diffs etc to see if you have been attacked and gotten
a trojan.

At least for FreeBSD ports, you'll get a fallback to our mirrors if
the file isn't there, so there is little problem with just removing a
wrong release.

So: New release numbering for ANY change.

Yet ... Mauricio suggested that this is little different than the
tar.gz being corrupted on upload.

I am working on something that makes it easy to deal with this, but
right now, doing anything other than uploading the corrected .tar.gz
would engender a lot more work than I have time to do. Later, it'll be
a single command. But for now, I think that for *this* change
(Archive::Tar::Minitar 0.5.1) I will be replacing the corrupted
tarfile.

-austin