On Sat, 02 Mar 2024 at 20:19:47 +, Simon McVittie wrote:
> I have proposed a change for glib2.0/experimental at
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
> implements the "delete the old postrm" approach
An equivalent glib2.0 change is now in unstable.
On Mon, Mar 04, 2024 at 04:08:37PM +, Simon McVittie wrote:
> Copying context from elsewhere in the thread, Sam Hartman wrote:
> > 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
Copying context from elsewhere in the thread, Sam Hartman wrote:
> 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?
to which I replied:
If libglib2.0-0 continues
> "Matthew" == Matthew Garrett writes:
Matthew> I agree with the conclusions drawn here, but feel that it's
Matthew> possibly worth making a stronger general statement that
Matthew> policy should never prevent the implementation of a
Matthew> well-considered simple solution.
I agree with the conclusions drawn here, but feel that it's possibly
worth making a stronger general statement that policy should never
prevent the implementation of a well-considered simple solution. I would
like some further analysis of Sam's proposal, though - I don't think
there's any
On Sat, 02 Mar 2024 at 20:19:47 +, Simon McVittie wrote:
> I have proposed a change for glib2.0/experimental at
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
> implements the "delete the old postrm" approach.
I've uploaded this to experimental, incorporating feedback
On Sat, 02 Mar 2024 at 20:19:50 +, Simon McVittie wrote:
> I am currently downloading all versions of libglib2.0-0 that have
> existed on amd64 as tracked by snapshot.d.o. My plan is to extract their
> DEBIAN/postrm, import them into a git branch and go back through the
> history that way.
I have proposed a change for glib2.0/experimental at
https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
implements the "delete the old postrm" approach. I would appreciate
review and comments on whether this is something that would be acceptable
to upload to experimental, and/or to
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
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
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
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
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
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
14 matches
Mail list logo
