[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Changelog URI in Release and Hashes in .diff/Index


speaking as an apt developer I have three 'little' inquiries for dak
and/or at least would like to hear some feedback on the matter:

1. Changelogs

Currently basically every tool is hardcoding specific URIs to places
where changelogs are published online. At least for the libapt-based
tools we intend to fix this and will ship code to actually properly deal
with the download of these files, so that there is hopefully just one
place to hardcode URIs in… expect that I would like to remove this
hardcoding, too, preferably, espcially as it seems to be different

Debian "http://metadata.ftp-master.debian.org/changelogs/CHANGEPATH_changelog";;
Ubuntu "http://changelogs.ubuntu.com/changelogs/pool/CHANGEPATH/changelog";;
Ultimedia "http://packages.ultimediaos.com/changelogs/pool/CHANGEPATH/changelog.txt";;
(there was a fourth variant, but the repository is dead now)

where CHANGEPATH is e.g. 'main/a/apt/apt_1.0.10.1' (for packages build
by the source package apt) as this seems to be the only constant in this.

So, I would like to request that the field
Changelogs: http://metadata.ftp-master.debian.org/changelogs/CHANGEPATH_changelog
is added to Release files, so that hardcoding can eventually be
stopped. (and apt tools survive the next change to the place where the
changelogs are). I considered briefly to make this even more variable
than just a single variable, but that quickly becomes annoying to
implement and support in clients.  On the other hand, forcing servers to
use a certain path consistently seems rather limiting, especially as
based on the current examples, Debian seems to be the odd apple here…

2. Hashes for the compressed pdiff files in .diff/Index

Currently we have only hashes for the uncompressed pdiffs in
SHA1-Patches.  I would like to request the addition of SHA1-Download,
which lists the hashes for the gz-compressed files, ideally with the
'<patch>.gz' filename.

This way tools like apt can check if they really downloaded a good file
before potentially extracting a gz-bomb or just any randomly broken

Additionally, that would at least document our .gz usage here. Clients
could be told to support other compressors if we eventually encounter
one where it makes sense to switch to.

3. different Hash algorithms in .diff/Index

Currently, we have only SHA1 around, which is okay, but not great and
even if the totally patched up file will be checked with the hashes
listed in the Release file it would still be better to check
intermediate results with other hashes, too. Supporting different hashes
here could eventually enable us to drop certain hashes even.

So, every field available as SHA1-* should be available as <Hash>-*,
where <Hash> is e.g. SHA256. If the fields are grouped by hash or
grouped by field type isn't important, I would just like to suggest not
splitting them into different sections as old clients might not expect
this and bark on such a file (older apt's would do).

All three things if implemented as suggested are already supported by
apt in debian/experimental (git, the pdiff thing even in experimental
archive) in case you want to try/see a client using it, but I am fine
with changing any of this if need be. I was just implementing it to see
how viable those things would turn out to be in 'real life'.

(Unfortunately my python knowledge is close to non-existent, so I will
refrain from trying to write a patch for your, daks and my sanity.)

Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature

Reply to: