[OpenIndiana-discuss] [oi-dev] Moving on with postgresql

Sun Apr 18 17:23:48 UTC 2021

On April 18, 2021 3:13:41 PM UTC, Austin Kim <freennix at gmail.com> wrote:
>[Sorry to cross-post to oi-dev but wanted to reply to the thread]
>
>On Apr 18, 2021, at 6:07 AM, Andreas Wacknitz <A.Wacknitz at gmx.de>
>wrote:
>> 
>> Am 18.04.21 um 02:37 schrieb Austin Kim:
>>> On Apr 17, 2021, at 7:22 PM, Till Wegmueller <toasterson at gmail.com>
>wrote:
>>>> Hi Gary
>>>> 
>>>> I use Postgres and extensions for all Applications I develop
>professionally and privately.
>>>> 
>>>> We use mostly 12 and upwards 13 being the standard and I am waiting
>for 14 to hit. The last Bugfix release for 9.5 was on 2021-02-11 so
>quite recently.
>>>> 
>>>> I would love to have 13 and modern 12 packaged, especially as we
>have a build server for them sponsored by the Oi community. So we know
>it builds even on current develop.
>>>> 
>>>> My preference for the record is to have 13, 12 and 11. Older ones
>should only be used for people still needing them. AWS only offers
>those in their offerings as well, so not many people will want 10 or
>older.
>>>> 
>>>> -Till
>>>> 
>>>> On 17.04.21 18:46, Gary Mills wrote:
>>>>> OI currently has postgresql versions: 95 96 10 11 12 .  The OI
>>>>> default, in shared-macros.mk, is 95 .  However, the postgresql
>>>>> developers report that 95 is unsupported, but 13 is available and
>>>>> supported.  Something has to change in OI to move forward with
>>>>> postgresql.
>>>>> Here are some actions that could be taken with OI.  We could
>change
>>>>> the default version to 10.  I, myself, would prefer 11.  We could
>>>>> obsolete 95.  I'd prefer obsoleting 95 and 96.  We could add
>version
>>>>> 13, but only after 96 is obsoleted.  We should limit the number of
>>>>> postgresql versions in OI, after all.  Finally, we could make no
>>>>> obsoletions or additions, retaining even the unsupported 95. 
>Which
>>>>> would you prefer?
>>>>> I have not investigated two questions.  Perhaps you can tell me? 
>What
>>>>> are the consequences of obsoleting 95?  What are the consequences
>of
>>>>> the default change?
>>> Hi,
>>> 
>>> Sorry for posting to this list as I’m only an OpenIndiana user, not
>a developer, but PostgreSQL is the DB I use most.
>> This is perfectly fine.
>> I just want to chime in here and say: You don't need to be a
>developer
>> in order to get involved in OpenIndiana!
>> Of course it is helpful to know some programming languages and build
>> systems. But many for aspects you don't need to be a professional
>> programmer.
>> 
>> At the moment we lack volunteers in almost all areas, even those not
>> related to updating packages. Eg. we need people to enhance or update
>> our documentation,
>> we need testers and of course people who care for some packages.
>> 
>> Nobody started as an expert in any of these areas. I am willing to
>help
>> people to get involved, eg. we can have video conferences where I can
>> demonstrate and teach how to update packages.
>> 
>> Of course you need to devote some resources (time, build or test
>> environment, ...). I can assure you that you will learn a lot about
>> OpenIndiana, Solaris and other operating systems.
>> And you will see some insanity related to software development,
>> especially open source software development where projects make heavy
>> changes (like change the build system) in minor or even micro
>releases.
>> 
>> Andreas
>
>This is the nicest message I have ever seen on any mailing list.
>
>One of the things that attracted me to OpenIndiana (apart from Sun
>Microsystems having been so generous and selfless funding UNIX labs in
>underserved CS departments, engineering schools, and universities, not
>just in the United States but even around the world—I once visited a
>country in the Middle East where annual per capita GDP was under US
>$1000 and walked into an engineering school lab where I was surprised
>to see all the servers and workstations were donated by Sun
>Microsystems with a plaque from Sun on the wall) (and also apart from
>the VERY heavy lift on Sun Microsystems’ part to open-source
>OpenSolaris—which they never had to do but to me just exemplifies the
>core values and character of the company) was that unlike the *BSDs no
>one working on OI AFAIK receives any financial compensation for their
>contributions; it seems to be purely a labor of (often thankless) love,
>which is inspiring.
>
>Personally in the future as time permits I hope to be able to
>contribute to updating the Project’s WWW site pages and then work on
>updating OI’s online docs to reflect the current state of OI.  I really
>would like to see OI’s online docs and WWW content better reflect all
>the hard work and effort all the OI developers have been putting into
>it, from Alasdair Lumsden to Alexander Pyhalov to everyone contributing
>today.
>
>As purely an OI user, I have a few initial suggestions (read: wishlist
>items:)
>
>0.  The creation of a new, dedicated “oi-doc” mailing list for future
>use for an OI “Documentation Project” team and others interested in
>contributing to/updating/revamping OI documentation and user guides
>(this might reduce cluttering up oi-dev with future
>documentation-related threads);
>
>1.  Going forward, not only announcing new Hipster releases on
>OpenIndiana-announce, but also major security patches (for example,
>when CVE-2021-3156 related to _sudo_ was patched at the end of
>January/beginning of February, at the time I was subscribed only to
>OpenIndiana-announce and not to oi-dev or any of the Illumos mailing
>lists and didn’t find out about the patch until happening to come
>across it on OmniOSce’s mailing list); and
>
>2.  I know this is totally random and off-topic, but when naming OI IPS
>packages à la (from Till W.’s earlier e-mail):
>	PACKAGE                                             PUBLISHER
>	pkg:/database/postgres-common at 9.5.24-2020.0.1.0     openindiana.org
>	pkg:/service/database/postgres-10 at 10.16-2020.0.1.0  openindiana.org
>	pkg:/service/database/postgres-11 at 11.10-2020.0.1.0  openindiana.org
>	pkg:/service/database/postgres-12 at 12.5-2020.0.1.0   openindiana.org
>	pkg:/service/database/postgres-95 at 9.5.24-2020.0.1.0 openindiana.org
>	pkg:/service/database/postgres-96 at 9.6.20-2020.0.1.0 openindiana.org
>what would you all think about possibly adopting an OpenIndiana
>convention that going forward the version number part following the “@”
>be named according to a standard format such as the following:
>	…@Maj.Min[.Rev]-YYYY.M.D.B
>	where the Major, Minor, and (if present) Revision numbers are taken
>from the corresponding version number of the upstream source;
>	where YYYY, M, and D are the year, month, and day whereon the upstream
>source was downloaded by the IPS package builder; and
>	where B could just be incremented from 0 in the case of subsequent IPS
>package releases built from the same upstream source version (that was
>downloaded on that particular YYYY.M.D)?
>Having the full YYYY.M.D date code would be helpful to users
>considering installing and/or upgrading to that version by quickly
>indicating what the date was as of which the upstream source used was
>current, which could potentially be helpful in the case of, for
>example, trying to figure out if the package likely includes a security
>patch incorporated upstream on a given date.
>
>Austin
>
>“We are responsible for actions performed in response to circumstances
>for which we are not responsible.”  —Allan Massie, _A Question of
>Loyalties_, 1989
>_______________________________________________
>openindiana-discuss mailing list
>openindiana-discuss at openindiana.org
>https://openindiana.org/mailman/listinfo/openindiana-discuss

Thanks for the inputs :) 

Many good ideas there, just got a comment about version strings: there is a sort of standard, I think going back to Sun times, about the fields in that string, with 2020.0 happening (IIRC) to be the distro release tag, like 151.8 way before it. 

There is a minor number somewhere there for bumps of the recipe with same upstream version, e.g. applying patches, and `pkg info (-r) packagefmri` should report the packaging timestamp, I think. Maybe having the oi-userland commit hash would be helpful too.

Notably, most recipes take the upstream tarball and apply some patches to integrate with the OS (e.g. SMF services) or add security patches or configure different options. Upstream version alone does not convey all the source used, and download time should be irrelevant assuming that a published upstream version remains immutable, which is very rarely not so. To the point that all used tarballs have checksums saved in the oi-userland recipes specifically to detect unexpected changes, whether sinister or transport/storage problems. And I believe the build server has (maybe even serves?) a copy of everything it ever packaged.

Hope this helps,
Jim Klimov

--
Typos courtesy of K-9 Mail on my Android