Package: tech-ctte
Severity: normal
X-Debbugs-Cc: debian-d...@lists.debian.org, debian-gtk-gn...@lists.debian.org,
vor...@debian.org
I'm requesting advice from the tech-ctte (or anyone else with relevant
knowledge, e.g. the dpkg team or the drivers of the time64 transition)
on how to resolve glib
Re: Simon McVittie
> libglib2.0-0t64 could gain a preinst that deletes
> /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm. This is a clear
> Policy violation, but perhaps between closely cooperating packages
> (glib2.0 and, er, glib2.0) it would be the least-bad answer to this?
That doesn't
Hi Simon,
On Fri, Mar 01, 2024 at 11:50:22AM +, Simon McVittie wrote:
> Background
> ==
Thank you for explaining the details so clearly.
> - for giomodule.cache (per-architecture), the file is simply deleted by
> postrm remove
For this one (but not gschemas.compiled), I am wonderi
Are there solutions in the space of having glib2.0-0 continue to exist
as a package depended on by glib2.0-0t64 or depending on the new library
allowing you to replace the postrm?
That might create a space in time where glib2.0-0.so does not exist, but
we probably have more flexibility there than
Hi Helmut (2024.03.01_14:58:10_+)
> For this one (but not gschemas.compiled), I am wondering whether
> installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright
> might work. That is a file that is going away and therefore, removal of
> libglib2.0-0 should cause libglib2.0-0t64.pos
On Fri, 01 Mar 2024 at 13:21:51 +0100, Christoph Berg wrote:
> > Possible solution: other ideas?
>
> Make glib2.0-t64 use a different cache filename?
I'm not happy about the idea of introducing long-term divergence in
the upstream code as a result of a Debian-specific packaging problem;
I think w
6 matches
Mail list logo
