Hi, Jim.
On 12/22/16 03:22 AM, Jim Klimov wrote:
We had a sort of a discussion on IRC today, which ended up in a choice better
made or at least discussed by community than by the back-alley dealers ;)
So, as software evolution marches on, some projects' newer releases bring new
features, bugs and ABI/API incompatibilities that make them different from
older releases - and sometimes not backwards compatible (most projects try to
make updates easy for their consumers, some don't).
As a result, the distro, such as OI/Hipster (and especially Hipster, posing as
bleeding-edge rolling-release), has to balance and make a choice between:
a) providing only the newest versions of libs/apps (accept PRs that integrate
a new version and remove old ones);
b) also provide older releases at least partially (e.g. libs that can be
runtime-linked against by older binaries - especially if new ABI is not
backwards-compatible and/or shared-library's SONAME numbers changed; or even
headers, pkgconfig snippets, etc. that can be built against from source -
especially if APIs changed), at least in cases where someone (distro
maintainers, PR authors) believe that lack of old files can be an issue for
end-users - but note that moving forward is often not an issue for binaries, if
the ABIs were declared well and kept compatible by upstream sources;
c) don't rush for newest releases - ain't broke don't fix; backport CVE fixes
to existing old-version recipes and be reluctant against new unknown bugs in
new developments; perhaps try to stay on par with software versions delivered
by stable releases of other distros like Debian, RHEL/CentOS or FreeBSD (which
often considerably lag behind bleeding-edge as well) and pick up their security
and bug fixes ;)
I'd like to separate libraries and applications.
In general case we want to provide only latest version of application if
we can.
There are several classes of exceptions, however. These are databases
(when storage format changes between major releases), translators (when
language can significantly change between releases). and some
applications with significant changes in configuration and ABI for
third-party modules (like apache 2.2 and 2.4). Did I miss something here?
As for libraries, I'd go from consumers. I'd be reluctant to add library
just to have it. If we add library without consumers, we even can't be
sure that it actually works as expected. With consumers we can at least
consider that it works for this consumer. So, I'd consider applications
first-class citizens, not libraries.
When do we need to add new major version of some library? If we look
from this point of view - only when some application requires this or,
perhaps, when existing library has significant issues which cannot be
fixed without updating to new major version.
Now, what can we do when we decided to bump library to new major
version? First of all, I'd consider if all in-gate consumers can be
switched to new version. If they can't, we should ship several versions
so that both of them can be used (good examples are gtk2/gtk3, bad
examples - libevent/libevent-2 - these needed significant patches to
coexist). Let's consider, all oi-userland consumers can be switched to
new version.
In this case we have a lot of question - do we ship old version or drop
it? Do we ship just old binaries or all files (headers,pkgconfig),
necessary for development? If we preserve old library, when are we going
to drop it?
I don't have good answers on these questions. So far I've checked if
some library is rather wide used (for example in SFE). If it's not, I'd
rather drop old version and introduce flag day.
I suppose these answers are closely related to having releases and
guaranteed stable API/ABI. So, that we can guarantee that this ABI is
not broken before next major release... Damn, it doesn't work with
Hipster, as it means we'll have not only support one stable release, but
several branches of stable releases.... OK, next idea... This ABI is
preserved for several next releases/snapshots.... Seems more real in
current situation, but for how many snapshots should we keep some
libraries? What libraries should be protected by such guarantees? I'd be
reluctant to give such guarantees for mate/gnome libraries. In theory we
could give such guarantees for some Xorg libraries, but not all... What
about other? Can we create transparent rules, which objects are
protected by ABI-compatibility-guarantees and for how long?
Can we do it without having /stable ?
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
_______________________________________________
openindiana-discuss mailing list
[email protected]
https://openindiana.org/mailman/listinfo/openindiana-discuss
