On Tue, Jul 09, 2019 at 01:53:33PM +0200, Julian Andres Klode wrote: > fields in extended_states when installing packages; and a Release Please don't. We talk every so often about having a way to tell dpkg to store data for us in status, we should eventually do that. It just gets ugly if that data becomes outdated due to human intervention. > file can declare other repositories as allowed; for example, it > declares a Amended-By field with one match per line > (lines being ORed together): A bunch of derivatives work by using e.g. Debian as their main package source and add their own repo as supplementary source for their own packages as well as to ship hotfixes before they are included in Debian. So packages can flip flop between Debian and the derivative as origin quiet liberally and I can't imagine Debian to declare in Amended-By to be open to everyone … > Potentially, another repository can declare to amend other repositories, > which would then cause apt to prompt you to accept that repository when > running update, showing the patterns it specifies, and the repositories > matching this: … which would be handled this expect that it now sounds like Amended-By works the other way around now. Anyway, I think tracking the source of an installed package would be good for various reasons (reproducible to name just one). Adding metadata on which repo can provide packages which are considered upgrades to packages originally coming from other repos I consider a different feature relatively similar to pinning to a point that it might be better to have a human friendly interface on top of pinning making use of the data to allow a human to declare the intend without too much room for error. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature