Fatal Aptly metadata corruption issue

[john....@gmail.com]

Help!!!

Aptly seems to keep repo pool metadata independent of the package metadata. They both keep the package signatures, and they had better match or there is no way to recover.

For unknown reasons, I have a repo where these have become different on a few packages. Most of the time this does not cause an issue, but when it causes a problem I have to resort to backups to recover. I have a suspicion that there is a locking issue between the API and the CLI interfaces, but cannot confirm that as the cause.

I can very easily reproduce the problem at will with a known set of packages. The problem is not identifiable until you attempt to publish the repository.
E.g:
$ aptly repo copy app-production app-dev my-package_1.4-3.2_amd64
$ aptly publish drop app
$ aptly snapshot drop snap-app-dev-latest
$ aptly snapshot create snap-app-dev-latest from repo app-dev
$ aptly publish snapshot \
-distribution=company-app \
-component=dev,testing,stable,production \
snap-app-dev-latest \
snap-app-testing-latest \
snap-app-stable-latest \
snap-app-production-latest
Loading packages...
Generating metadata files and linking package files...
ERROR: unable to publish: unable to process packages: error linking file to /home/me/.aptly/public/pool/dev/m/my-package/my-package_1.4-3.2_amd64.deb: file already exists and is different

I am unable to fix this using any identified mechanism. Running aptly db cleanup and/or aptly db recover do not fix this. It may be possible to hand-insert the correct metadata in the repo, but that is probably at least a day of hacking that I would like to avoid every time this bug hits me.

The root cause of the problem appears to be aptly incorrectly using the somehow-damaged metadata from the repo instead of the metadata from the package, leading to a metadata mismatch that is only detected at publish time.

I'm currently using Aptly-1.0.1, the latest available. This version has been updated several times over the last several years. Is there a version of Aptly that will always update the repo metadata using the package metadata instead of the current broken behaviour? Or, is there a tool or undocumented command or flag to correct the pool metadata to match the actual packages?

[Andrey Smirnov]

John,

It's not corruption of any way. https://www.aptly.info/doc/feature/duplicate/ gives overview on that:

"""
When aptly is publishing repository, it would give an error if conflicting package files (same name, but different content) are put together in one package pool. Package pool is shared by all published repositories with the same component and prefix. The same applies to switching snapshots or updating published repositories: if previous state and new state contain two conflicting packages, aptly would give an error.
"""

You have conflicting packages in several published repos under the same publish root. It's not problem with aptly, but rather problem with your packages and/or publish layout. 

You can get additional information in https://wiki.debian.org/DebianRepository/Format 

--
You received this message because you are subscribed to the Google Groups "aptly-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aptly-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[john....@gmail.com]

On Wednesday, 12 July 2017 15:40:27 UTC-4, Andrey Smirnov wrote:
> It's not corruption of any way. https://www.aptly.info/doc/feature/duplicate/ gives overview on that:

That does not appear to be the issue. In this case, I am doing an aptly repo copy from one distro component to another (dev to production) in order to trigger the problem, so the same content in the pool just is being exposed in a different component. The distro successfully publishes until I do this repo copy operation, which just duplicates the package ref in another component and does not alter the pool content. Since the package must be the same package for this to occur, publishing a package with different content is not the problem.

What I want in order to correct the db is some means of specifying that the package metadata of the package being repo copied is the master copy, not whatever it thinks is different metadata.

[Andrey Smirnov]

That's not related to DB at all. 

Path "/home/me/.aptly/public/pool/dev/m/my-package/my-package_1.4-3.2_amd64.deb" is occupied by some file already. Let's assume it's not something leftover, but it's part of previous publish to the same root. Your new publish operation tries to overwrite it with different file. It happens in the filesystem. 

I would ask a question - how many packages with filename "my-package_1.4-3.2_amd64.deb" do you have? Answer should be more than one, otherwise there's no way this thing might have happened.

[john....@gmail.com]

Ok, problem solved, with a bit of coaching.

At some time in the past and for unknown reasons, a duplicate package occurred.
Since aptly package show did not handle this situation, Andrey recommended that I locate the duplicate using the find command, which found several copies of 2 different files with the same name in the pool/ and public/pool/ dirs.

So, there was a duplicate situation created at some time in the past.

The one referenced in the Packages file for the known repo was the one being used by everyone, so I deleted the other one in 2 places and ran aptly db cleanup. This discovered the 2 files removed, and fixed the db. Re-publishing the repo now succeeds.

Thank you Andrey!!