11:57:58 <spwhitton> #startmeeting
11:57:58 <MeetBot> Meeting started Mon Feb 19 11:57:58 2024 UTC.  The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:57:58 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:58:01 <spwhitton> #topic Roll Call
11:58:03 <spwhitton> Sean Whitton
11:58:08 <Emperor> Matthew Vernon
11:58:19 <helmut> Helmut Grohne
11:58:49 <Myon> Christoph Berg
11:59:04 <roehling> Timo Röhling
12:05:46 <spwhitton> #topic Recruitment
12:05:50 <spwhitton> #action spwhitton to start internal poll
12:06:10 <spwhitton> #topic Bug#1060700: Impact of problems caused by aliasing on declared Conflicts
12:06:15 <spwhitton> I am not caught up on this.
12:06:36 <spwhitton> But I share MatthewV's sentiment that it
12:06:41 <spwhitton> it's all fairly unnerving.
12:07:05 <spwhitton> Are there people who have thought through helmut's messages and have opinions?
12:07:20 <Myon> I don't think anyone ever claimed the general situation is ok, but that's where we are now
12:07:38 <Myon> so we are looking at workarounds anyway, not perfect solutions
12:08:07 <spwhitton> right.
12:08:14 <helmut> In principle, we could apply more mitigations to make more situations safer, but getting there requires work (plus cleanup work later) and we also risk getting this wrong as we are practically writing dead code (only to be exercised in rare circumstances).
12:08:28 <Emperor> Mm
12:08:30 <spwhitton> the only completely general solution on the table is to say in the release notes that certain things aren't supported during the upgrade
12:08:51 <spwhitton> I think I prefer that to writing code.
12:09:01 <helmut> Changing release notes is planned in any case
12:09:36 <spwhitton> does anyone think we should try to do anything beyond that?
12:09:43 <helmut> A number of resulting problems do not render systems unbootable. Hence, we can detect and repair them after upgrade.
12:09:45 <Myon> I think the cost of that extra code is also quite high (maintainer time)
12:10:01 <spwhitton> right.
12:10:08 <Emperor> I think suggesting dpkg --audit (and then some destructions for what to do with the output is good).
12:10:26 <Myon> so I'd tend to only fix the "bad" problems that have a real chance of actually appearing in practise
12:10:37 <roehling> +1
12:10:52 <helmut> Where we risk making systems unbootable, stronger mitigations are in place (often causing them to persist into forky+1)
12:11:02 <Emperor> I agree that what isn't supported should go into RN. What is in that set of things is a point of contention. E.g. I think "dpkg -i thingy.deb that you wanted to upgrade" isn't something that obviously shouldn't be supported
12:11:33 <spwhitton> I guess we want to issue advice saying that the policy violation is okay, that the release notes should say what is not supported, that you should probably run dpkg --audit, and that there may exist undiscovered problems and the sort of things that might trigger them.
12:11:48 <helmut> the gzip policy violation will be no more
12:11:59 <Emperor> which is good :)
12:12:07 <helmut> the plan now is to extend gzip.preinst with code supporting zutils in migrating its diversion
12:14:21 <spwhitton> Emperor: do you mean doing that dpkg -i invocation in the middle of a dist upgrade?
12:15:08 <Emperor> having had a dist-upgrade stop part-way-through for whatever reason
12:15:19 <helmut> What we're looking into now is a balancing act. The more elaborate mitigations make some package operations safer, but they incur more development time and more maintainer time (they need to be reverted and then later dropped) and risk being wrong (by never actually being tested).
12:15:39 <Myon> that risk is real I think
12:16:25 <spwhitton> could we say what you *are* allowed to do in the middle of a stopped upgrade?  rather than what you're not?
12:17:06 <helmut> if the package you are trying to dpkg -i has already been unpacked and then failed somehow (i.e. you reinstall), the /usr-merge issues shouldn't come to light
12:17:17 <Myon> "if you think that some file got lost, run dpkg --audit, and apt install --reinstall affected package" sounds acceptable for the RN
12:17:57 <Emperor> Am I the only person who has seen apt get stuck and ended up doing some dpkg invocation to get an upgrade through?
12:18:11 <helmut> no :)
12:18:15 <roehling> I've seen it, but only on Ubuntu machines
12:18:38 <Myon> the last case I had was on a buster->bookworm upgrade
12:19:18 <spwhitton> helmut: what do you think of Myon's proposal?  we should definitely keep what's in the notes short.
12:19:44 <Myon> plus some description what the issue with files moving is
12:20:34 <Myon> "we think we've covered all packages in Debian, but there might be external packages and cases that have been overlooked"
12:20:43 <helmut> spwhitton: we'll be doing that regardless. To me that proposal is more like "the amount of effort we put into this is sufficient"
12:20:46 <Emperor> I think I'm opposed to advice of the form "only operations starting apt ..." are supported
12:20:59 <Emperor> given my past experiences
12:21:19 <Myon> definitely, I often end up doing dpkg -i *.deb in /var/cache/apt/archives/
12:22:03 <Myon> helmut: I think the effort is already sufficient, yes
12:22:30 <helmut> The advice will be more like: Please run ... after the upgrade and check for missing files. In particular, perform this check if you had to run dpkg directly during the upgrade or you suspect missing files.
12:22:47 <Myon> +1
12:22:59 <Emperor> that seems reasonable
12:23:26 <spwhitton> among the possible other work that could be done, it doesn't seem like the TC is in much of a position to choose between the options
12:23:44 <Myon> with some explanation that we think there should be no problems, and that this is for safety
12:23:44 <spwhitton> cos there is infinite such work.
12:24:55 <Myon> perhaps also running --audit *before* the upgrade so any problems don't get blamed on usemerge
12:25:18 <spwhitton> how about running --audit before, after, and during if you do anything else?
12:25:28 <spwhitton> before and after every 'apt ..' cmd.
12:25:31 <helmut> dpkg --verify | grep '^.\{11\} /usr'
12:25:38 <Myon> spwhitton: too much
12:25:55 <Emperor> I think verify not audit?
12:26:00 <spwhitton> Myon: for most people that means running it twice in total.
12:26:17 <spwhitton> or if no local pkgs, not at all.
12:26:28 <Myon> that makes it look like the problem is really really likely
12:26:36 <Myon> I'd just tend to keep the instructions short
12:26:45 <helmut> From my point of view, we do not have to debate the contents of RN here. There'll be a MR and discussion there, but the general sentiment is that users should be informed.
12:26:51 <Myon> ack
12:26:59 <Emperor> --audit just checks if you have any packages in a part-done state, --verify actually looks at the contents
12:27:10 <spwhitton> okay
12:27:30 <Emperor> (--verify produces output on both systems I have handy to test it on, mind)
12:28:20 <helmut> --verify does not consider a configured --path-exclude
12:28:29 <Myon> "yay"
12:28:32 <helmut> it also reports any modified conffile
12:28:56 <Myon> ok anything else on this item?
12:29:11 <helmut> No. The "we're doing good enough" part is fine to me.
12:29:16 <spwhitton> okay
12:29:23 <spwhitton> could someone summarise these thoughts to helmut's bug
12:29:36 <spwhitton> s/these thoughts/this discussion/
12:29:44 <spwhitton> Myon: could you?
12:29:53 <Myon> yes
12:30:38 <spwhitton> #action Myon to write summary of discussion to the bug & close it
12:30:40 <spwhitton> thank you.
12:30:43 <spwhitton> #topic Any Other Business
12:30:48 <spwhitton> anything?
12:30:55 <Emperor> not from me
12:32:08 <spwhitton> thank you all for changing the meeting time.  one more month of this, if that's okay.
12:32:21 <Myon> thanks all
12:32:25 <spwhitton> and we might need a new time with a new ctte member, anyway.
12:32:30 <spwhitton> #endmeeting