On Tue, Jul 09, 2019 at 03:49:09PM +0200, David Kalnischkies wrote: > 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. We should do that, yes. > > > 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. Both work the same way, basically you can image that if A is amended by B, then A and B form one repository group, and are considered the same source. What's different is that Amended-By is used to automatically have new repos you add join that group, and Amends can be used by new repositories to join existing groups. Tough maybe I'm missing something, and it's unclear what happens if you have a configured repository that "Amends" a new one - will you then get prompted when adding that, becaused it's not "Amended-By"? Maybe the difference does not make much sense, though, and just one Amends field works fine. > > 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. Obviously one is the building block for the other. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature