support of changes files

[deknos]

Hi,
we would like to replace our repository-tools with aptly.
It would be nice, if aptly supports changes-files.

We build our own Debian-Packages and we include them into dak and reprepro-repositories. Since changes-files include a list of source- and deb-Packages, it is easier to import own packages with that file, since automatically both types are included into our repository.

[smira]

@deknos, do you mean files produced by dpkg-genchanges (1), right?

[deknos]

Yes, dpkg-genchanges(1). i should have mentioned that, sorry.

[filippog]

👍 that would be indeed a great addition, a few ideas thinking out loud:

basic functionality would include support to process a .changes file I'd say and include in a repo (or a snapshot too perhaps?) whatever files are referenced in the .changes (possibly also checking the checksums?)

more advanced functionality can include authenticating (usually via gpg signature) and authorizing (e.g. like reprepro does) users via .changes files so that the usual debian toolchain can be used (debuild, dput, etc)

thanks again for aptly!

[smira]

I'm trying to understand use case for .changes files. aptly can import files from directory (automatically finding all .dsc and .deb files). aptly automatically picks up all the files referenced by .dsc file. What would processing of .changes files give on top of that?

[filippog]

the main advantage I see is being able to use the full debian toolchain to upload packages to aptly, so debuild would generate a .changes file for me, sign it and dput would upload it. So being able to describe a change to an archive, and a way to authenticate and authorize it which isn't necessarily being able to write to the aptly database files. What do you think?

[smira]

Sample .changes file: http://paste.kde.org/pkbaaoff8

[smira]

aptly could be configured to use Distribution field as local repo name (destination)

[shadeslayer]

The paste is only going to last a week, so I'm repasting the example here

Format: 1.8
Date: Thu, 27 Nov 2014 13:24:53 +0000
Source: calamares
Binary: calamares calamares-dbg
Architecture: source amd64
Version: 0+git20141127.99
Distribution: sid
Urgency: medium
Maintainer: Rohan Garg <rohan@kde.org>
Changed-By: Rohan <rohan@kde.org>
Description:
 calamares  - distribution-independent installer framework
 calamares-dbg - distribution-independent installer framework -- debug symbols
Changes:
 calamares (0+git20141127.99) sid; urgency=medium
 .
   * Update from git
Checksums-Sha1:
 79f10e955dab6eb25b7f7bae18213f367a3a0396 1106 calamares_0+git20141127.99.dsc
 294c28e2c8e34e72ca9ee0d9da5c14f3bf4188db 2694800 calamares_0+git20141127.99.tar.xz
 d6c26c04b5407c7511f61cb3e3de60c4a1d6c4ff 1698924 calamares_0+git20141127.99_amd64.deb
 a3da632d193007b0d4a1aff73159fde1b532d7a8 12835902 calamares-dbg_0+git20141127.99_amd64.deb
Checksums-Sha256:
 35b3280a7b1ffe159a276128cb5c408d687318f60ecbb8ab6dedb2e49c4e82dc 1106 calamares_0+git20141127.99.dsc
 5576b9caaf814564830f95561227e4f04ee87b31da22c1371aab155cbf7ce395 2694800 calamares_0+git20141127.99.tar.xz
 2e6e2f232ed7ffe52369928ebdf5436d90feb37840286ffba79e87d57a43a2e9 1698924 calamares_0+git20141127.99_amd64.deb
 8dd926080ed7bad2e2439e37e49ce12d5f1357c5041b7da4d860a1041f878a8a 12835902 calamares-dbg_0+git20141127.99_amd64.deb
Files:
 05fd8f3ffe8f362c5ef9bad2f936a56e 1106 devel optional calamares_0+git20141127.99.dsc
 097e55c81abd8e5f30bb2eed90c2c1e9 2694800 devel optional calamares_0+git20141127.99.tar.xz
 827fb3b12534241e119815d331e8197b 1698924 devel optional calamares_0+git20141127.99_amd64.deb
 e6f8ce70f564d1f68cb57758b15b13e3 12835902 debug optional calamares-dbg_0+git20141127.99_amd64.deb

[oCCtet]

Use case for the .changes file would be this: the uploader signs the .changes file, and uploads it (possiby via anonymous ftp) using dput. The server then verifies that the signature is from a known uploader, and proceeds to verify the contents (binary and source package checksums). If these verifications pass, the packages are added to pool.

If the verifications fail, the upload shall be rejected.

Due to this lack of uploader authentication/authorization, the aptly repo add <repo> <dir> cannot really be used to set up an incoming/ system without additional tooling.

[smira]

@oCCtet thanks for the great case!

[kived]

I wrote my own script to process .changes files and import packages into aptly. My .changes files aren't signed, so the script doesn't handle that part, but it compares file sizes and checksums before importing. It works for me using inoticoming to trigger it, YMMV.

https://gist.github.com/kived/68ad4f035a80fb2488d3

[smira]

Done in master, available as nightly build aptly_0.9.6~dev+53+g3c20b54.

Documentation: http://beta.aptly.info/doc/aptly/repo/include/

[npf]

Hi, issue #278 reports a issue when including a package to a backports distribution.