Skip to content

Instantly share code, notes, and snippets.

@smira
Created July 6, 2017 20:48
Show Gist options
  • Save smira/efce8d9e049b2aa944eee6bc4f7b2cb2 to your computer and use it in GitHub Desktop.
Save smira/efce8d9e049b2aa944eee6bc4f7b2cb2 to your computer and use it in GitHub Desktop.
aptly 1.1.0

This is DRAFT of release notes

aptly 1.1.0 release is following (a bit late) scheduled every 3 months release of aptly.

Custom Filesystem Publishing

aptly supported configuring number of S3 and Swift publishing endpoints for a long time, but local filesystem publishing was limited to default directory ~/.aptly/public and hardlinking files. There was number of requests to allow use of symlinks or file copy to support publishing to different filesystems and shared locations like NFS.

With PR #521 from @seeraven aptly supports configuration of custom filesystem endpoints. Each endpoint has its own filesystem root, it might support either hardlinks, symlinks or simple file copy to reference files from aptly internal package pool.

Internal Package Pool

aptly stores package files deduplicated internal package pool (under ~/.aptly/pool by default). MD5 checksum was used to build file path in the pool, which had two consequences:

  1. MD5 checksum was required to pick location, so mirrors without MD5 checksums were not supported (#228, #442).
  2. In unlikely event when two different package files with same filename had same first two bytes of MD5 checksum, aptly would fail to import file (#329).

In order to overcome those problems, package pool and internal package file storage was changed. Now aptly always recalculates checksums on files being downloaded or imported, making sure each file has full set of checksums (including SHA512). Location of package files in the pool now includes more bytes of SHA256 making conflict unlikely.

When upgrading from previous version, aptly would be able to find and use previously downloaded or imported package files, but new files would be stored in new locations. This means that downgrading from aptly 1.1.0 to previous versions is no longer supported (it's not advised to do that for any version of aptly, but with package pool changes this would make aptly loose track of package files). There are no special actions to upgrade aptly to 1.1.0.

Database Locking

There were several issues with aptly api serve with -no-lock which got fixed (#431, #582). With 1.1.0 every aptly command on startup performs 10 attempts to reopen DB if database is locked. This makes easier to use CLI from cron or in CICD environments (#401). Number of attempts is configurable with -db-open-attempts flag for every command. If you want to go back to pre-1.1.0 behaviour, use -db-open-attempts=0.

Changes

aptly sorts search results and package lists (#135, #214) with respect to correct version ordering.

It's allowed to create snapshots of empty repos (#288).

aptly now correctly matches checksums for indexes while mirroring (#376).

aptly packages from repo.aptly.info now correctly list xz-utils in dependencies (#395).

aptly doesn't abort execution if Contents generation fails (#451, #533).

aptly generates detailed log while resolving dependencies with -dep-verbose-resolve flag (#508).

aptly can now optionally skip checking package files while downloading from the mirror (#520).

aptly supports setting and inheriting from the mirror values for Origin, NotAutomatic, BadAutomaticUpgrades while publishing (#577, thanks @sliverc).

Development

Development documentation is now available.

aptly code is verified with set of linters both for Go source code and Python functional tests.

Files for back completion are now part of aptly source repository for easier packaging and PRs.

Download

Debian packages and binary distributions for various platforms are available at https://www.aptly.info/download/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment