Environments are indeed mainly useful as building blocks to make tasks easier to use, although we went back and forth a fair bit on exactly how to organize them and look them up.

My thought was that remove+add in a transaction would be sufficiently atomic, though that's probably a frequent enough thing to want to do that it would be worth having a Python method wrapping it.

debian:archive's only direct items are debian:suite collections, which have a name as part of the standard metadata applying to all collections. The lookup names on debian:archive would descend into each of the contained suites.

For debian:suite, I think you're right that we should copy a few extra pieces of information from the artifacts, as otherwise they'll be lost after expiry.

overrides are a standard thing in Debian-format archives, implemented by both dak and Launchpad: the general idea is that packages supply default values for component/section/priority but the archive managers have final authority on those, and also the overrides double as a way to detect whether an upload contains package names that aren't currently known to the archive and therefore should go through NEW review.

I'll put together an MR tomorrow with some corrections based on this. Thanks!

Thanks for the explanations!

Regarding:

For debian:suite, I think you're right that we should copy a few extra pieces of information from the artifacts, as otherwise they'll be lost after expiry.

Since artifacts might disappear, and thinking of after an artifact have been removed: I wonder if we should keep somewhere in the DB the list of files of the artifact, with their hashes (and file lengths?). Would this be useful to the users?

The use case is that the artifact expired (e.g. a source package). The user creates a new one (importing, etc.). Something is not quite right and the user would like to confirm that the new source package is the same as the one that has been used in the past.

Also: should, besides the files and hashes, anything else be saved? (metadata of the artifact).

Or perhaps, at this stage, if the artifact is gone, it's gone. This extra things can be added in the future if there is a need.

I apologise if this was already discussed, I didn't have time to follow the MR comments as they happened.

I'm not really inclined to keep copies of detailed file-level information at the moment. I think that will get quite complex quite quickly, and I'm not sure we have a sufficient grip on the use cases and whether it would be enough of a solution to them (e.g. knowing that hashes differ is all very well, but then you may be left rather unsatisfied as there isn't much else you can do ...).

https://salsa.debian.org/freexian-team/debusine/-/merge_requests/521 makes a couple of small tweaks.

The name/version etc. copies in debian:suite do need to be sorted out, but they're currently awkward, essentially due to https://salsa.debian.org/freexian-team/debusine/-/issues/269. Right now we'd need to have a dictionary due to using debian:binary-packages, which makes it tempting to put them in overrides, but they don't fit into the set of overrides as generally understood in Debian. Once suites are referring to binary packages one at a time, then it would be possible to just have name, version, etc. per-item keys - but I think we need to get the binary package reorg done first. Can the other bits wait?