Re: targets to handle gnu dist procedures?

[Alexandre Duret-Lutz]

>>> "Karl" == Karl Berry <address@hidden> writes:

 Karl> John Darrington (cc'd here), who maintains the GNUbik package, made this
 Karl> suggestion:

 >> With the new ftp upload procedures, shouldn't the automake targets be
 >> changed appropriately?  In particular:
 >> 
 >> The dist target should generate the package.tar.gz.asc file and the
 >> dist-check target should verify that this signature is indeed valid.

 Karl> I myself don't think it should be part of dist and distcheck.  Doing the
 Karl> signature requires typing the pass phrase.  It often takes a dozen runs
 Karl> of dist[check] before the release is actually ready (at least for me).
 Karl> I would be quite annoyed at having to do the signature stuff on every
 Karl> test run.

Actually the release procedure is so different for each package
that it seems impossible to automatize.

In the case of the Automake package, for instance, the release
procedure (after you have modified the version number and
regenerated dependent files) is

   1) distcheck
   2) commit to CVS, and tag the release
   3) upload to gnu.org and sourceware.

The version bump should not be committed to CVS before distcheck
succeeds, and the package should not be uploaded without being
tagged in the repository.

If files in the package were using RCS keywords, the above
procedure would not be enough, because the commit would modify
the files.  Hence an extra step is needed:

   1) distcheck
   2) commit to CVS, and tag the release
   3) dist
   4) upload to gnu.org and sourceware.

(If the RCS keywords are actually processed in some way by the
package, it may even be safer to rerun distcheck the second
time.)

Such rules can be expressed in the Makefile fairly easily.  For
instance here is how Automake does it.  Other package, like
Coreutils, have a much more developed release rules (generating
announcements and the like); you may want to look at it for
inspiration.

## Create a distribution, but do not upload it
cvs-dist: maintainer-check
## Make sure clcommit exists (we use it at the end of cvs-dist).
        @if (clcommit --version)>/dev/null 2>/dev/null; then :; else \
          echo "Get clcommit from module cvs-utils on Savannah."; \
          exit 1; \
        fi
## Make sure the NEWS file is up-to-date.
        @if sed 1q $(srcdir)/NEWS | grep -e "$(VERSION)" > /dev/null; then :; 
else \
          echo "NEWS not updated; not releasing" 1>&2; \
          exit 1;                               \
        fi
## Build the distribution
        $(MAKE) distcheck
## Finally, if anything was successful, commit the last changes and tag
## the release in the repository.  We don't use RCS keywords so it's OK
## to distribute the files before they were committed.
        cd $(srcdir) && clcommit && \
          cvs -q tag -c `echo "Release-$(VERSION)" | sed 's/\./-/g'`

## Create, then upload the distribution.
cvs-release: cvs-dist
        case $(VERSION) in \
          *[a-z]) dest=alpha;; \
          *)      dest=ftp;; \
        esac; \
        $(srcdir)/lib/gnupload $(GNUPLOADFLAGS) \
          --to sources.redhat.com:~ftp/pub/automake \
          --to $$dest.gnu.org:automake $(DIST_ARCHIVES)

It's important to write any additional check and release
instructions on top of dist or distcheck, rather than inside
these targets (e.g. using hooks, or overriding these targets).
Basically your users should be able to run `make dist' and `make
distcheck' regardless of what source control system YOU decided
to use, and regardless of where YOU usually make your releases.

 Karl> Having a separate target to do it, however, could be useful.  Maybe even
 Karl> make the directive file and sign it, too, with a variable that defaults
 Karl> to $PACKAGE for the directory name.  (Some variables would also be
 Karl> necessary for the gpg invocations, of course.)

Automake ships with a script, gnupload, used in the above
cvs-release rule, that will sign and upload all your files to
multiple locations, and generate the directive file if needed.

(The real motive for this script was that I didn't want to type
my passphrase 4 times to upload Automake.  Unfortunately gpg
will not sign several files in batch, and I refuse to have my
passphrase memorized by a long-lasting process such as an
agent.)
-- 
Alexandre Duret-Lutz