| 5 Feb 2021 |
 emorrp1 | ? why 990 ? under default configuration it should be either 100 or 500 | 20:39:43 |
 dxld | sure but why allow this additional friction to exist? | 20:39:52 |
 andrewsh | what friction? | 20:39:59 |
| dxld | In reply to @emorrp1:freedombox.emorrp1.name
? why 990 ? under default configuration it should be either 100 or 500 990 is for default-release 500 is without default-release | 20:40:04 |
| dxld | look at the apt_preferences manpage | 20:40:10 |
| andrewsh | updating psycopg once during the lifetime of a release isn’t much | 20:40:13 |
| andrewsh | * updating psycopg manually once during the lifetime of a release isn’t much | 20:40:24 |
| andrewsh | even if it’s twice | 20:40:30 |
| dxld | well, my thinking is that if someone relies on u-a to actually be unattended the're missing (potential security) upgrades for no good reason now because of this issue | 20:41:32 |
| dxld | hell I would have never thought using packages from backports together with u-a is so involved when I started doing this | 20:42:06 |
| dxld | obviously freedombox also has this problem where we want people to be able to just install a box at their mum's house and have it manage itself | 20:42:59 |
| dxld | so I just don't see how you can consider "whatever just do it manually" to be a solution here even if it just happens rarely | 20:43:39 |
| andrewsh | backports is not something to automatically update to
if you want that, you have to edit your config by hand and opt into that yourself | 20:45:12 |
| emorrp1 | so you want something like a client side config option for half way between NotAutomatic and ButAutomaticUpgrades - something like DependenciesAutomatic? | 20:45:15 |
| andrewsh | unless you do that, you need to opt-in to each breaking update | 20:45:28 |
| andrewsh | I think this is good enough | 20:45:38 |
| dxld | emorrp1: I suppose, yeah. If you're considering solving this at the archive level. | 20:46:25 |
| emorrp1 | andrewsh: I think it's reasonable to say that apt install -t buster-backports foo should be configurable to mean "make it work no matter when I happened to run the command", since if you run that now you will get psycopg2 from backports without having to whitelist every dep in the tree | 20:49:14 |
| emorrp1 | sure you don't want to run apt upgrade -t buster-backports, that would be pretty insane but once you've declared you want a leaf package from backports it should be possible to follow it without interruption | 20:50:42 |
| dxld | yeah I was thinking the pinning machinery might just have to consider packages transitively though I'm not sure that's compatible with the current semantics of pinning.. | 20:52:02 |
| emorrp1 | dxld: I don't think it needs to be archive level, just wanted to re-use those concepts - please do raise a wishlist for something like Apt::Get::Upgrade-Allow-Dependencies-Automatic | 20:52:56 |
| dxld | since the prio value just gets computet for each package/version individually | 20:53:01 |
| dxld | emorrp1: I am definetly going to raise a bug about this, but here's another crazy idea for a workaround: can we ship an appropriate preferences file in doc/examples or some such that one could symlink to? :) | 20:55:54 |
| dxld | happy to provide a patch and test this out obviously | 20:56:37 |
| emorrp1 | interesting idea, but I would hope eventually that could be generated from a dh_something because all it really is is an alternative format of the deps listed in debian/control with knowledge of what's currently available in the stable repo | 20:59:44 |
| dxld | uuh, that's a good idea | 21:00:05 |
| dxld | transitive deps might be a problem still | 21:00:41 |
| dxld | does it really need to know what's in stable? | 21:01:58 |
| dxld | it is true that it would be redundant to declare pins for packages that aren't in stable but I don't think it would hurt anything | 21:03:00 |
| emorrp1 | well it does know at the point in time of building, just list all the installed deps that have come from backports | 21:03:10 |
