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

[Till Wegmüller]

Hello Everyone


Am 22.12.2016 um 10:44 schrieb Alexander Pyhalov:
> 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?

I very much agree with the Seperation of Libraries and applications. 
Libraries are part of the applications. Some Applications require the 
same parts an thus they are shared. Which makes sense. Now here comes 
the magic of modern Package management Systems. In pip for example 
(python) you name the version of the dependency you have. When all 
Dependencies that need to installed are computed you end up with the 
most moden version still compatible with your requirements.

I would suggest we don't have two or more versions in Userland but have 
them available in the hipster IPS repo, so that IPS can work its magic 
if a Application needs an older version.

Generaly having the most up to date version of Applications is the best 
solution. A good example why would be xscreensaver. The author works 
with only one version where he fixes bugs and add features. When 
something brakes you tell him that and he fixes it. So why not help his 
efforts and work togheter with him? This not only helps the developer 
but also us. When we make the authors aware of us and help them make 
their software run on our systems and help fix bugs we found, we become 
both first class citizens of each other. Reducing Workload on our side 
even further as we don't have to constantly port.

 > 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?

As for stability what are the guaranties from Upstream Developers? How 
can a small team of develpers offer more than the Upstream developer? 
Most of the times this question has been answered with using old 
versions. The logic being that what worked 10,000 times will work 10,001 
times. But is that really true? When using SLES in my previous work I 
had more than once the Problem that Patches from SUSE broke more than 
Upstream Linux. Simply because SUSE had less developers that could See 
those Problems. We have even less developers. So the Development modell 
that upstream uses can help more than whatever effort we make.
I would suggest a wiki page where we keep track of the Major Application 
stacks we use and what they offer for guaranties and if we would 
recomend them for usage based on experience. (Packaging and Software 
using it). I bet that Upstream dev will like to see how their work is 
perceived aswell.


Greetings
Till