Re: Uncoordinated upload of the rustified librsvg
- Date: Sun, 4 Nov 2018 02:50:48 +0100
- From: Samuel Thibault <sthibault@xxxxxxxxxx>
- Subject: Re: Uncoordinated upload of the rustified librsvg
Jeremy Bicha, le sam. 03 nov. 2018 21:04:49 -0400, a ecrit:
> On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski <kilobyte@xxxxxxxxxx> wrote:
> > Perhaps we should quickly upload a revert, using the last good version of
> > librsvg, before things degrade? Effectively removing librsvg on 11 archs
> > (not counting non-official ones) stops any GUI there. Including proverbial
> > fvwm.
> It sounds to me like you're saying that to fix librsvg being out of
> date on 11 arches, we need to make it out of date on every
> What is the actual consequence of the latest librsvg being unbuildable
> on those arches? The old binaries won't automatically be removed
> there, right?
No, but various problems quickly arise:
- no new arch can build it.
- if a bug needs to be fixed in it for ports it can't be built.
- if it is involved in a transition, it can't be rebuilt, thus holding
the transition for those archs.
- ftpmasters don't like lingering binaries.
A temporary solution could be to upload the previous version under a
different source package name, but that builds the same binary packages,
and only on archs which don't have rust (yet). Such package won't get
upstream updates etc. but it doesn't need to enter testing anyway.