Commit 614b0c2a authored by Eric Timmons's avatar Eric Timmons
Browse files

v0.1.0

parent 46b1fa68
Pipeline #4747 canceled with stages
in 7 minutes and 28 seconds
......@@ -3,6 +3,10 @@ include:
- remote: 'https://gitlab.com/clci/gitlab-ci/-/raw/release/v1-stable/ci-cache.yml'
- remote: 'https://gitlab.com/clci/gitlab-ci/-/raw/release/v1-stable/clpm.yml'
stages:
- test
- deploy
.test:
extends:
- .clci ci cache per job
......@@ -43,3 +47,11 @@ generate docs:
artifacts:
paths:
- doc/
publish docs:
variables:
CL_TAR_FILE_TAG: $CI_COMMIT_TAG
stage: deploy
trigger: cl-tar/cl-tar-site
rules:
- if: '$CI_COMMIT_TAG =~ /^v[0-9]+(\.[0-9]+)*(-.*)?$/'
# cl-tar-file changelog #
## Unreleased
## v0.1.0 - September 22, 2021
First release!
......@@ -3,16 +3,18 @@ formats. Currently supported are the POSIX ustar, PAX (ustar with a few new
entry types), GNU, and v7 (very old) formats.
This project is rather low level and is focused exclusively on reading and
writing tar file entries using streams. Therefore, it contains no functionality
to automatically build archives from a set of files on the filesystem or write
the contents of a file to the filesystem. Additionally, there are no smarts
that read multiple physical entries and combine them into a single logical
entry (e.g., with PAX extended headers or GNU long link/path name
support). This approach is taken to both improve portability (the CL spec has
no facility for things like detecting symlinks or modifying/reading file
owners, etc.) and properly separate concerns. Another system will be written
that does the non portable bits and other systems can use tar-file directly if
they have a need to perform low level operations on tar archives.
writing physical tar file entries using streams. Therefore, it contains no
functionality to automatically build archives from a set of files on the
filesystem or write the contents of a file to the filesystem. Additionally,
there are no smarts that read multiple physical entries and combine them into a
single logical entry (e.g., with PAX extended headers or GNU long link/path
name support). This approach is taken to both improve portability (the CL spec
has no facility for things like detecting symlinks or modifying/reading file
owners, etc.) and properly separate concerns.
For a higher level library that reads and writes logical entries, as well as
includes file system integration,
see [cl-tar](https://gitlab.common-lisp.net/cl-tar/cl-tar).
This project is a fork
of [Nathan Froyd's archive library](https://github.com/froydnj/archive). Much
......
;;; -*- mode: lisp -*-
(asdf:defsystem #:tar-file
:version "0.10"
:author "Nathan Froyd <froydnj@gmail.com>"
:version "0.1.0"
:author "Eric Timmons <eric@timmons.dev>"
:maintainer "Eric Timmons <eric@timmons.dev>"
:description "A package for reading and writing tar files."
:description "A package for reading and writing physical entries from/to tar files."
:license "BSD-style (http://opensource.org/licenses/BSD-3-Clause)"
:depends-on ("alexandria" "babel" "trivial-gray-streams" "uiop"
"40ants-doc")
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment