Comment 20 for bug 1780501

On Fri, Aug 03, 2018 at 11:06:38AM -0000, Egmont Koblinger wrote:
> Hey guys,
>
> Hope I'm not speaking up too late.
>
> It's indeed a bit nasty situation we're in, and I am also a little bit
> responsible for this. When updating the PCRE fixes for 0.52 I focused on
> the actual work, and ignored (just ported blindly in "autopilot" mode)
> the annotation changes. I should've stopped and asked "what the heck is
> this?". Sorry for that!
>
> In the mean time vte itself is also somewhat responsible for the mess by
> silently fixing its python bindings in backwards incompatible ways.
> (Mainstream 0.52 fixed feed_child() not to take a third parameter, it
> was broken before and required an explicit length. The same happened to
> feed_child_binary() in 0.46 which may have been the reason for someone
> to (accidentally or intentionally) sneak in the revert of this to the
> PCRE patch.)
>
> So a "faulty" vte update has already been released for bionic, breaking
> 4 packages we're aware of (ubuntu-release-upgrader, terminator, guake,
> cubic). Maybe there's one or two more at most, but I don't think so.

This "faulty" vte update is a regression though in that something which
used to work, calling feed_child() with three parameters, no longer
does and causes other software to break. This is not in line with the
Ubuntu Stable Release Updates policy. Additionally, we don't know what
other software, packaged or not, would be broken by this change and that
is why its best to keep what we had when Ubuntu 18.04 was released.

> On the other hand, this change "fixes" vte to be like mainstream,
> which is a huge advantage for anyone wishing to manually install
> vte-based software.

> I assume you don't intend to carry these changes forever. Brian Murray
> from comment 10:
>
> > I agree that having downstream API differences is bad and that it
> shouldn't be fixed for cosmic
>
> I can only parse this sentence assuming a typo: "*should* be fixed for
> cosmic", am I right, or what am I missing?

I mean that we should leave vte2.91 alone for cosmic.

> ubuntu-release-upgrader has already been fixed to cope with either
> signatures if I understand correctly, and the other three will also need
> to be fixed eventually.

They will need to fixed but that should happen to the packages in cosmic
and not require SRUs for an unknown quantity of packages Ubuntu 18.04.

> At this point, if it was dozens of packages that broke, I'd agree with
> reverting the vte change. If vte received a broken change, I'd agree
> with reverting it.
>
> However, vte actually received a fix, which happened to break 4 apps
> that were strictly speaking broken (to adjust to broken vte), and
> they'll need to get fixed anyway.
>
> In this situation I find it much clearer to escape forward rather than
> retreat, and just fix those 4 broken packages. For all of them it's a
> trivial change, you don't even need to handle two different APIs with a
> try-expect, you can just go for the final correct version (two
> parameters) straight away.

> I understand that the overhead right now is somewhat bigger for
> releasing 4 updates rather than 1. However, it results in a much clearer
> situation that gets rid of the differences from mainstream, more easily
> supportable for the forthcoming almost 5 years and is much better for
> any user who hack around on their system (i.e. install vte-based apps
> from various sources). I do believe that – cleanliness and better
> overall quality of bionic with this approach over the other put aside –
> it's even cheaper to fix those 4 packages now, than to maintain and
> support this crazy oddness for the rest of bionic's lifetime.

Could you elaborate as to what cost you think there is to maintaining
this oddness in Ubuntu 18.04?

--
Brian Murray