> On 27 Dec 2024, at 20:46, Jonathan Kamens <j...@kamens.us> wrote:
>
> On 12/27/24 7:34 AM, Geert Stappers wrote:
>> Yeah, it feels wrong that dpkg gets file system code, gets code for one
>> particular file system.
>>
> I disagree. If there is a significant optimization that dpkg can implement
> that is only available for btrfs, and if enough people use btrfs that there
> would be significant communal benefit in that optimization being implemented,
> and if it is easiest to implement the optimization within dpkg as seems to be
> the case here (indeed, it may only be possible to implement the optimization
> within dpkg), then it is perfectly reasonable to implement the optimization
> in dpkg. Dpkg is a low-level OS-level utility, it is entirely reasonable for
> it to have OS-level optimizations implemented within it.
I’m also on the same boat with Geert. I don’t think dpkg is the correct place
to integrate fs-specific code. It smells like a clear boundary/responsibility
violation and opens a big can of worms for future of dpkg.
Maybe, a wrapper (or more appropriately a pre-post hook) around dpkg which
takes these snapshots, calls dpkg with appropriate switches and makes the
switch can be implemented, but integrating it into dpkg doesn’t makes sense.
In ideal case, even that shouldn’t be done, because preferential treatment and
proliferation of edge cases make maintenance very hard and unpleasant, and dpkg
is critical infrastructure for Debian.
Cheers,
Hakan
>
> jik
>
