Re: [EXTERNAL] [PNG] Meeting minutes - Jan 6th, 2025

On Mon, Jan 6, 2025 at 1:43 PM Seeger, Chris (NBCUniversal) <
Chris.Seeger@nbcuni.com> wrote:

> In Github, for libpng, I see “Tags” but no “Releases” for specific
> versions. Because this version contains new functionality (cICP), is it
> easy  to make a “Release” based on the new “Tag”.  I’m hopeful it might
> encourage a larger group to make the effort and upgrade to the new library
> version.
>

The things that are marked as "tags" in fact **are** releases, but they are
"patch" releases so typically OS developers take them automatically ASAP -
as soon as their verification tests have passed.  Certainly when Cosmin
releases 1.6.45 it will immediately go into the Gentoo release queue.  I
expect to see a ~dev release of Gentoo with it in after a couple of days
(Gentoo releases continuously in two stages, basically "~ "i.e. "bleeding
edge" and "stable").

TL;DR:

The patch releases cannot co-exist; there is only one at once.  The major
releases (e.g. 1.6 vs 1.8) do coexist; an OS distribution can and typically
will carry a completely new DLL for 1.8 at the same time as one for 1.6.
Therefore the OS can ship a mix of apps some of which use 1.6 and some 1.8.

Typically Debian style systems will only take a patch release if it doesn't
break something obvious and will back it out if a break turns up later.
Major releases are easier for them because they can co-exist; think throw
it against the wall and see if it sticks.  You can see that with Qt; any
major release of Qt can be installed regardless of any other major
release.  You can see the problems of not doing this with other libraries
which don't use the methodology or get it wrong.  There were enormous
problems with two different versions of libssl.

A patch release does not require recompilation of the apps that use the
base release.  An app can be compiled against any version of 1.6 and used
against any other version.  The only condition (which, incidentally, I have
consistently argued against) is that the app must not use new ABIs unless
it is absolutely sure it will never run on an OS with a version prior to
the introduction of the new ABI.  I think I had a log discussion
with @ChrisB about how this works but maybe it was on github, not this
list.  Most people are not familiar with how DLLs work.

This does not apply at all to systems like Windows and MacOS which do not
ship libpng.  On those systems apps which use libpng have to bundle their
own build.  Whether or not they take a new build when a patch is released
depends on the internal decisions of the relevant corporation; they have to
balance the instability of new, untested, code against any advantage it may
give.  Typically they abide by the rule, "If it ain't broke don't fix it."

Windows, since the oleaut32 disaster (termed "DLL hell") has developed a
system which allows multiple applications to share the same DLL even across
patch relesases.  Windows can run multiple versions of the nominally same
DLL at the same time.  This was developed after I left Microsoft so I am
unfamiliar with the precise details; someone who does understand
"assemblies" may wish to comment, Cosmin?

Android and iOS don't ship libpng so apps build their own.  The security
issues probably mean that those builds cannot be shared.  I developed the
"minconfig" stuff to accommodate this; a build of libpng can easily be
stripped of all unnecessary poo.  So far as I can see the app developers
will have to pull the new release and rebuild their apps (unlike on Windows
and all modern UN*X derivatives, including MacOS).  Since Cosmin will be
releasing a patch release many devs will do that, it will just work, even
if they use new ABIs.

MacOS itself is OpenBSD but still doesn't distribute libpng.  I assume they
have their own internal, independent, PNG handling code.  I have every
reason to believe Windows is in the same position.  Such code is
monumentally more simple than libpng and the work to add chunk support will
only be limited by the motivation (or lack) to add such support.

John Bowler