Re: how to make a hypermail tar.gz-package

From: Kent Landfield <kent_at_hypermail-project.org>
Date: Wed, 17 Nov 1999 15:45:31 -0600 (CST)
Message-Id: <199911172145.PAA27905_at_rkive.landfield.com>

# On Tue, 16 Nov 1999, Kent Landfield wrote:
#
# > First is, the maketgz and FILES file are there for the administative
# > purposes of just a couple people. They are of no use to the average
# > hypermail user. Shouldn't tools like this, that are only used for
# > building official distributions of hypermail, be in a separate CVS
# > baseline such as one named "hypertools" ?
#
# If they were many, big and extensive I would agree. But now, by keeping them
# in the main distribution archive we allow anyone at any time to build a new
# archive very easy. You could even make re-package hypermail again after you
# have untared it and thrown away the original tarball and it would become an
# exact copy.

I currently have a couple others. There should be a file that keeps all the baseline tags and a description of what they are for. I understand what you are trying to accomplish but it's just as easy to tar the whole directory and send it where you want as opposed to using the script.

# > A problem with the script at present is that it does not allow to
# > directly use what's in the CVS baseline.
#
# True. I usually make a 'cvs update' in the root anyway before I go ahead and
# play. I didn't want to add that dependency in maketgz, since it builds
# tarballs, not necessarily tarballs with the very latest sources from the CVS
# baseline. It is up to you to pick 'em.

Ok. Then I'll make the CVS an optional feature and leave the original funtionality.

# > It also does not support tagging the CVS files that make up the
# > distribution.
#
# True. But if you don't do any magic tricks, and if you're using the latest
# and fanciest sources you would simply commit everything and tag them just
# after you'd run maketgz. I've done that numerous of times.

My problem is that I want to have this as a fully automated operation so there are no mistakes.

# > Also the script modifies patchlevel.h that is created as part of the
# > distribution. That new patchlevel.h is then not consistent with what is
# > in the CVS tree.
#
# ... if you're not committing, that is true yes. I usually commit it after
# the maketgz has run. Having the script do this modification makes it
# absolutely sure we never release a tarball with the wrong version number
# string inside.

Right.

# It may not be the perfect tool yet and it may need more tweaking, I still
# believe that having a tool like this that builds the archives is far better
# than lots of manual steps that have to be done without mistakes every time.

I totally agree. ;)

# I'm not convinced that such a strict connection between maketgz and the CVS
# management is needed. But I'm not very much against it either. ;-)

And if it works both ways.... :)

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: kent_at_landfield.com             http://www.landfield.com/
Email: kent_at_nfr.net                   http://www.nfr.net/
Search the Usenet FAQ Archive at http://www.faqs.org/faqs/
Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/

Received on Wed 17 Nov 1999 11:47:49 PM GMT