File already exists and is different. Workaround without upgrading?

[mjramtech]

From what I've read I assume the issue I've come across has been fixed - https://github.com/smira/aptly/issues/329. However Debian Stretch still only offers 0.9.7-1 and installing from source or unstable is an administrative headache, so I was wondering if a safe workaround is available in the short term? I'd really rather not start poking around deleting files without posting here first. Thanks for any pointers.

Full scenario:

aptly version: 0.9.7

If I do:
aptly publish repo repo1

The response is:
ERROR: unable to publish: unable to process packages: error linking file to .../.aptly/public/pool/non-free/a/alarm-app-cie/alarm-app-cie_0.1.1-575_armhf.deb: file already exists and is different

So I thought, given we can do without it, this might resolve the issue:
aptly repo remove repo1 alarm-app-cie_0.1.1-575

But the output is just:
Loading packages...

I'd expect something to confirm deletion, such as:
[-] alarm-app-cie_0.1.1-575

I've tried a DB cleanup and no difference.

All packages are added to the repository using an automated process, which uses -remove-files=true -force-replace=true, so there should never be any actual duplicates. There's also only one repository on the system, but it does support two architectures (armhf and amd64).

It's prbably worth mentioning that the are many versions (nightly builds) of some packages to support legacy, current and debug systems. So any bug that incorrectly identifies duplicates is likely to raise its head here eventually.

[smira]

This doesn't look like #329, usually there are two things which might lead to that:

• backup/copy aptly root broke hardlinks between public/ and pool/ subdirectories
• you have duplicate packages you're trying to publish (https://www.aptly.info/doc/feature/duplicate/)

[mjramtech]

Maybe a different issue then, but I've upgraded now so perhaps consign it to history? I ditched the repository before upgrading so don't know if upgrading would have fixed it, sorry (I'd already made a mess of things by manually deleting files in an attempt to fix it). There certainly hasn't been any backup/copy operation, at least not via human intervention, don't know if aptly performs these things autonomously at all. And again in reference to duplicate packages, there's just an automated process that adds packages with options -remove-files=true -force-replace=true, which as I understand it should never result in duplicates???

[smira]

So there are two dimensions - one repository/snapshot never contains duplicates, but when you start publishing several repos/snapshots under same root path, they share pool/ subdirectory (that's Debian package layout). That's where you can see this "problem". I put problem in quotes, as it's not a problem on its own - either you need to avoid duplicates, or use different publishing prefixes.

[mjramtech]

This instance of aptly only ever had one repo (and no snapshots). The repo did support two architectures though, if relevant. I should probably mention that this is one of three servers all autonomously hosting the same repo, that have the same packages uploaded to them nightly, but the other two servers didn't suffer these symptoms. The reason the are three servers is simply that they operate in different environments - debug (lan), trial (wan), and live (public). It was only the live server that started exhibiting the symptoms I opened this issue against, and this, perhaps ironically, is the server that sits there untouched for months at a time - there's certainly nobody ad hoc adding anything to the repo.

As I say I've upgraded all instances of aptly and all good so far, and I'm not trying to chase this as an issue, just letting you know what we saw. Thanks.

[smira]

So the error condition is really simple - aptly tries to put package file (hardlink) to public/pool/... location, but there's already another file with same filename. Whatever it was, it was there.

[mjramtech]

Yes, I guess so, but all packages are added with -remove-files=true -force-replace=true.

[haim0n]

Same issue here, aptly 1.2.0 , on ubuntu 14.04.05 docker.

aptly repo add -force-replace=true testing  /opt/aptly/upload/mypkg_1-6866-f6d29fa.deb 
Loading packages...
[-] mypkg_1-6866-f6d29fa_all removed due to conflict with package being added
[+] mypkg_1-6866-f6d29fa_all added

aptly publish -skip-signing update plato
Loading packages...
Generating metadata files and linking package files...
ERROR: unable to publish: unable to process packages: error linking file to /opt/aptly/public/pool/main/m/mypkg/mypkg_1-6866-f6d29fa.deb: file already exists and is different

aptly repo remove testing mypkg_1-6866-f6d29fa 
Loading packages...

[smira]

@haim0n this is not issue with aptly, it's an error related to the way you work with your packages https://www.aptly.info/doc/feature/duplicate/

In your case you can't gracefully update repo after replacing a package. So you should either publish drop and publish repo or enable -force-overwrite

[haim0n]

@smira thank you!
IMHO the issue should be changed to resolved, since there's a workaround.

[smira]

In short, if package contents are different, package should have a new version. Same version -> same package contents. At least within one distribution (e.g. if building for different Debian versions having same version should work, as they would be published as different distributions).

[ZamanOof]

In short, if package contents are different, package should have a new version. Same version -> same package contents. At least within one distribution (e.g. if building for different Debian versions having same version should work, as they would be published as different distributions).

I was on publish give -distribution= the version of debian, so if give it the same distro (debian) or as the issue with debian as #586 (comment)
and we can't consider overwriting is a solution,bcs effected on another dist
what mean of different ?in checksum,size?
what about a parameter to ask user, there is duplicate to overwrite it or not?