Next: , Previous: Automated Upload Procedure, Up: Automated FTP Uploads   [Contents][Index]


11.5.3 FTP Upload Directive File - v1.1

The directive file name must end in ‘directive.asc’.

When part of a triplet, the directive file must always contain the directives version, directory and filename, as described. In addition, a ’comment’ directive is allowed.

The version directive must always have the value ‘1.1’.

The directory directive specifies the final destination directory where the uploaded file and its ‘.sig’ companion are to be placed.

The filename directive must contain the name of the file to be distributed (item (1) above).

For example, as part of an uploaded triplet, a ‘foo.tar.gz.directive.asc’ file might contain these lines (before being gpg clearsigned):

version: 1.1
directory: bar/v1
filename: foo.tar.gz
comment: hello world!

This directory line indicates that ‘foo.tar.gz’ and ‘foo.tar.gz.sig’ are part of package bar. If you uploaded this triplet to ‘/incoming/ftp’ and the system positively authenticates the signatures, the files ‘foo.tar.gz’ and ‘foo.tar.gz.sig’ will be placed in the directory ‘gnu/bar/v1’ of the ftp.gnu.org site.

The directive file can be used to create currently non-existent directory trees, as long as they are under the package directory for your package (in the example above, that is bar).

If you upload a file that already exists in the FTP directory, the original will simply be archived and replaced with the new upload.

Standalone directives

When uploaded by itself, the directive file must contain one or more of the directives symlink, rmsymlink or archive, in addition to the obligatory directory and version directives. A filename directive is not allowed, and a comment directive remains optional.

If you use more than one directive, the directives are executed in the sequence they are specified in. If a directive results in an error, further execution of the upload is aborted.

Removing a symbolic link (with rmsymlink) which does not exist results in an error. However, attempting to create a symbolic link that already exists (with symlink) is not an error. In this case symlink behaves like the command ln -s -f: any existing symlink is removed before creating the link. (But an existing regular file or directory is not removed.)

Here are a few examples. The first removes a symlink:

version: 1.1
directory: bar/v1
rmsymlink: foo-latest.tgz
comment: remove a symlink

Archive an old file, taking it offline:

version: 1.1
directory: bar/v1
archive: foo-1.1.tar.gz
comment: archive an old file; it will not be
comment: available through FTP any more.

Archive an old directory (with all contents), taking it offline:

version: 1.1
directory: bar/v1
archive: foo
comment: archive an old directory; it and its entire
comment: contents will not be available through FTP anymore

Create a new symlink:

version: 1.1
directory: bar/v1
symlink: foo-1.2.tar.gz foo-latest.tgz
comment: create a new symlink

Do everything at once:

version: 1.1
directory: bar/v1
rmsymlink: foo-latest.tgz
symlink: foo-1.2.tar.gz foo-latest.tgz
archive: foo-1.1.tar.gz
comment: now do everything at once

Next: , Previous: Automated Upload Procedure, Up: Automated FTP Uploads   [Contents][Index]