• A bit further on dpkg aliasing support

    From Simon Richter@21:1/5 to All on Sun Dec 8 06:10:01 2024
    Hi,

    I've had a bit of time again, and got it to a state where I can detect
    and reject packages that try to unpack conflicting files. There is also
    a WIP tip on the branch that implements rudimentary Replaces handling,
    but that needs cleanup, because it copies the "does A replace B" code
    from unpacking instead of moving that to a library or similar.

    What's also not great is how removing files from other packages works --
    I've mostly stolen that from regular unpacking, but it feels
    insufficiently atomic to me (but so does the normal unpacking path).

    Current state: https://salsa.debian.org/sjr/dpkg/-/tree/wip/alias

    There are quite a few functions that take a pointer to a pkginfo and a
    pkgbin, and there seems to be an implicit understanding that the pkgbin
    is either the "installed" or the "available" member of the pkginfo. Does
    it make sense to replace the second pointer by a two-value enum?

    Also, while the entire thing is not yet ready for merging, getting
    feedback on some commits might be useful still to see if I'm going the
    right way at all here.

    Simon

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Simon Richter on Tue Dec 17 05:00:01 2024
    Hi!

    On Sun, 2024-12-08 at 13:59:53 +0900, Simon Richter wrote:
    Also, while the entire thing is not yet ready for merging, getting feedback on some commits might be useful still to see if I'm going the right way at all here.

    I've not looked into the branch, because I'm assuming this is still
    based on the same concept than the one you mentioned before(?). If so
    it should still have the same problems I listed (I think multiple
    times, so I feel this has been repeatedly ignore), where I mentioned
    this was not the way forward. I've also mentioned in the past (also
    multiple times), how I see this being handled, via the fsys metadata
    work as its base, which I've been doing in the background, and where
    any aliasing would be simply rejected, even though that cannot be
    deployed yet, given that we'd currently get file type conflicts.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)