On Mon, May 29, 2017 at 12:24:29PM +0100, Chris Lamb wrote: > Just to be clear, the patch is obviously an digusting hack and you > should not use it, hence the lack of a "patch" tag (!). Oh, no worries, we can manage. I mean, how hacky can it really be……… OH MY GOD, YOU ARE CALLING CURL!!111elf (lets start with some implementation criticism even if that wasn't your primary goal – Julian said most of it but lets recap for completeness as I will reference it later) As a cleanup I would suggest making the location of your JSON file an apt repository (aka: add an Release file mentioning the uncompressed and compressed versions of those files. Ensure the Release file has an "Architectures" field mentioning all supported architectures so apt isn't complaining about missing Packages files – as it will assume they are missing as they are empty, not because the repository doesn't support this architecture). You can then add that repository in your sources.list and tell apt to get it via acquire-additional-files.txt (See appstream, apt-file and "apt-config dump Acquire::IndexTargets" for examples – that can also deal with un/recompressing your file) That is good training as we will need that configuration bit even if the file would eventually end up alongside the others in the Debian repositories. JSON is a problem in Debian context, but lets ignore that for the moment. From a codepoint of view it will be most interesting to get a mapping from downloaded file to the relevant stanza about a source package. I would say hashes should work here given that they should be the same, so if we can find a download source and a source claiming reproducible for a package (version) with that hash we should be good – that would also avoid the extra step of mapping to source package. (mostly the end of implementation critic) From a user point of view I am not sure what to think here. It is probably going to be a hard sell to teach every repository owner to really be honest about reproducibility if I can save a lot of support time from users seeing scary warnings if I just declare all my packages as reproducible all the time – so perhaps its actually a good idea to never merge the data in the repository itself but have it from "independent" sources (similar to what I described above) [which makes the mapping all the more interesting code wise] showing all packages we don't have good info for as "unknown reproducible state" and allowing certain repositories (and packages) to be declared as good in sources.list (and an apt_preferences lookalike). It will also be interesting to figure out what "reproducible" means in super laymen terms as I am not sure users will understand it. We have trained people to understand "reproducible" in terms of bugs, but what that means in the context of installing binary packages… installing things is pretty reproducible, isn't it? Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature