[OpenIndiana-discuss] How many versions of libs/apps should OI provide?

cpforum cpforum at orange.fr
Thu Dec 22 18:47:01 UTC 2016


Hi all,


I think the update policy must depend on software reputation, type of release major, minor, extended support release (called  for exemple ESR for Firefox or ESV for bind and DHCP), non regression tests available.

 
Actually curl, squid, and apache httpd have both security advisories.

 updating them to new minor release is the best solution :
- Apache httpd from 2.4.23 to 2.4.25 (it's a minor release)
- same for Squid from 3.5.22 to 3.5.23 and curl 7.52 to 7.53.

 When backporting as RedHat/CentOS does, we don't know what is backported or not. It waste a lot of time
and nobody know what is really backported inside RHEL 6.8 bind 9.8.8rc1 ...

I think other software, compiling  out of the box as openldap, bind, dhcp (ESV branch only), openssl when changing 1.0.2h to 1.0.2j don't need backporting.


On the other hand, transitionning to a new major release  should be delayed (in some case, I think for exemple samba3 /samba4, and because expected major features are available, maintaining 2 versions is necessary)
 

> Message du 22/12/16 01:25
> De : "Jim Klimov" 
> A : "Discussion list for OpenIndiana" 
> Copie à : 
> Objet : [OpenIndiana-discuss] How many versions of libs/apps should OI provide?
> 
> 
> Hello all,
> 
> 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 ;)
> 
> All of these variants (and probably more can be thought of) have their valid pro's and contra's so it is not easy to pick one as an apparently best choice.
> 
> One aspect is being "friendly" to software used by end-users, especially those who migrated from an existing Solarish installation and use (or start out with) software binaries not coming from our distro packages. For them, an appropriate SONAME of old libraries with old ABIs can be a good safe harbor while they decide to stick with it or update - to distro userland packages, or something else - but either way, on their own schedule. This is a conservative choice, an argument in favor of (b).
> 
> Another aspect is being friendly to developers who want to directly work on, and port stuff to either OpenIndiana itself or just "something illumos/solaris-like", e.g. to verify portability during CI tests. These users would likely want or need either the latest versions of dependencies (argument for (a)), or a few versions of the latest releases in the projects' branches if several release trees are maintained on the upstream (argument for (a) and (b)).
> 
> And there is a notion of having less bugs, which may be gained by following strategy (c)... but perhaps becoming less interesting and relevant day by day.
> 
> As became clear from discussions (and history of PR reviews), the activists of the userland repo do have different opinions on this, and it is a good time to ask what the existing and potential users would prioritize? Do we have people who want their old bins to "just run"? Do we want people to use only (or mostly) the packages we provide in our ever-growing userland, or should we consider that someone might have rolled their own - and evicting older dependencies from our packages would upset their private existing builds? Do we have (existing, or a chance to catch) some migrant developers who want their shiny new code to build with the least friction and side quests to get the dependency ecosystem built first? Do we want stability if not stagnation in the rolling-bloody-release distro that many do use as production deployments? Or do we want a radical "always only everything new because upstreams deemed their stuff ready to release"? Or something in between to satisfy all of the above? :)
> 
> Thanks for your valuable insights and opinions,
> Jim Klimov (and those other guys who hanged out on IRC tonight and asked me to move the discussion to ML ;) )
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>



More information about the openindiana-discuss mailing list