[config-package-dev] usrmerge and dpkg-divert

Benjamin Kaduk kaduk at mit.edu
Wed Jul 21 16:53:20 EDT 2021


On Thu, Jul 15, 2021 at 10:20:09PM -0400, Geoffrey Thomas wrote:
[...]
> This only affects the case where you use the wrong path. As far as I can 
> tell, if you use the right path, everything is fine. However, a 
> consequence of usrmerge is that people aren't really supposed to care 
> about which path is "right."
> 
> I'm trying to figure out what, if anything, we should do about this. Some 
> options are:
> 
> - Add a NEWS entry + some docs saying that people need to be careful about 
> using the right path.
> 
> - Automatically try to determine whether you're using the wrong path. This 
> is trickier than it seems, because we do support the case where a config 
> package diverts a file that doesn't yet exist.
> 
> - For usrmerge-affected directories, on a usrmerged system, divert both 
> paths, and clean them both up on removal/undisplace. (I actually think 
> this might Just Work...)
> 
> - Push for a change into dpkg to sort this out, somehow. I do expect that 
> dpkg can be taught to figure its way around usrmerge, but I also expect 
> that the dpkg maintainer is very much uninterested in implementing it. 
> It's not clear to me whether the dpkg maintainer would be interested in 
> accepting a patch for it.
> 
> - Do nothing (or maybe update the website and the version in git with some 
> docs, but not the version in Bullseye).
> 
> Keep in mind that hard freeze is expected for this Saturday (see 
> https://release.debian.org/), so we'd very much need a freeze exception 
> for any option other than "do nothing."
> 
> Thoughts?

I suspect that we should add NEWS+docs for bullseye and investigate whether
"divert both paths" works as a longer-term mechanism.  I don't have
confidence that we can actually get confidence about that mechanism in time
for bullseye...

> I'll go ahead and file a request to pre-approve some sort of change so we 
> get on the release team's radar, at least.

Thanks!

-Ben


More information about the config-package-dev mailing list