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 _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
