Aptly reports conflict on addition for identical (architecture, name, version) but different filename

[alanfranz]

Hello,
I've come across a behaviour which I found puzzling at the beginning, but I think I've now found the source of the issue. using prepackaged aptly 0.9.7 on Ubuntu Trusty.

I use aptly in an automated fashion, where my CI system creates DEBs and adds them to aptly by invoking its command line; in this automated systems, a random suffix is prepended to DEB filename [see later why].

As an example, for my apt-current_1.7-27-jessie_all.deb deb file, the filename is tmpIwAWHDapt-current_1.7-27-jessie_all.deb. The package metadata has still apt-current as a name and the repo is handled properly by apt clients (i.e. apt-get install apt-current )

What does NOT seem to work is the "same (architecture, name, version)" check.

If I do:

aptly repo add jessie-apt-current-v1 /tmp/tmpIwAWHDapt-current_1.7-27-jessie_all.deb
aptly repo add jessie-apt-current-v1 /tmp/tmpIwAWHDapt-current_1.7-27-jessie_all.deb
aptly repo add jessie-apt-current-v1 /tmp/tmpIwAWHDapt-current_1.7-27-jessie_all.deb
aptly repo add jessie-apt-current-v1 /tmp/tmpIwAWHDapt-current_1.7-27-jessie_all.deb

repeatedly, aptly properly says

Loading packages...
[+] apt-current_1.7-27-jessie_all added

and exits with 0 every time.

Now, If I do:

/tmp$ mv /tmp/tmpIwAWHDapt-current_1.7-27-jessie_all.deb /tmp/CHANGEDapt-current_1.7-27-jessie_all.deb
/tmp$ aptly repo add jessie-apt-current-v1 /tmp/CHANGEDapt-current_1.7-27-jessie_all.deb
Loading packages...
[!] Unable to add package to repo apt-current_1.7-27-jessie_all: conflict in package apt-current_1.7-27-jessie_all
[!] Some files were skipped due to errors:
  /tmp/CHANGEDapt-current_1.7-27-jessie_all.deb
ERROR: some files failed to be added

The file is EXACTLY the same, just the filename changed, but aptly doest not properly detect that.

I noticed, as well, that within apt repos created by aptly the original filename is retained within the pool.

I would suggest (but I'm not sure if Debian/Ubuntu dictates anything different on the topic) that either an invalid package filename is rejected at the first upload, or that just the package metadata is employed and the filename is disregarded and ignored entirely.

About the random prefix that I employ:
AFAIR (but I'd need to verify, and I will if you tell me that I should since it could be an aptly bug) I had some issues when I wanted to use aptly to store some debs that don't have the "distro version suffix" within their version, i.e. let's suppose that I have two apt-current_1.7-27.deb , one is built for jessie, the other for squeeze, so they're different; I had some error reported (which I imagine were caused by the identical filename), I don't remember if it were on aptly repo add or snapshot publishing/switching.

[smira]

Package filename shouldn't matter that much (or shouldn't matter at all).

More on conflicting packages: https://www.aptly.info/doc/feature/duplicate/

aptly supports conflicting packages just fine in different repositories.

btw, there's clear bug when handling multiple duplicate package in single aptly invocation

[pmhahn]

See #552 for a similar issue, but that one is about updates while this one is for add and manually changed file names.

With my Debian Maintainer hat on: the canonical name for a package file is more-or-less defined by the metadata: ${name}_${version}_${architecture}.${type}, where $version is without the Epoch and $type is deb, but also can be udeb for µ-Debs used by the Debian Installer. There even is the tool dpkg-name to rename your files to the canonical naming.
So just renaming a file does not change the meta-data and the next dpkg-name run will undo the rename.
I don't know if aptly explicitly stored the provided file name or uses above described naming convention, but just renaming a package file is at least not a good idea.
(There is a second naming convention used by APT when it downloads files with an epoch in the version number, where that is included and separated by an :, which is hex-encoded as used in URLs.)