[oi-dev] some Newbie questions

Tue Dec 28 19:19:54 UTC 2021

Personally I'd like to request a perl tk package.

This can be used for TeXLive on OpenIndiana.

Currently the page https://tug.org/texlive/distro.html lists:

    Debian: aptitude install perl-tk
    Ubuntu: apt-get install perl-tk
    Gentoo: emerge dev-perl/Tk # older: dev-perl/tk
    ...

but no OpenIndiana.  However I'm sure that if there were a perl-tk package, then it'd work for TexLive install-tl.

It would be nice if you could just do "pkg install perl-tk" in OpenIndiana.

This is a personal opinion, I do not know whether such a package would be hard/difficult to make,
and whether it would be accepted.   But TCL/Tk is in the OpenIndiana repo.  TCL version 8.6.12,
which should be fine for TexLive as this requests TCL 8.5 or higher.

In fact I am sure perl/tk works, I compile it manually for the tlmgr -gui:

http://docs.openindiana.org/handbook/community/texlive/

Anyway if you would have a look at the Perl packages, I guess that would be a most welcome contribution.

Regards,
David Stes

----- Op 28 dec 2021 om 13:11 schreef oi-dev oi-dev at openindiana.org:

> Hello Tim,
> 
> thank you for the warm welcome. And thank you for the very valuable
> answers and hints. They helped already a lot. I guess I 'll need some
> more time to get to the nitty-gritty details. But I hope to be able to
> upload a first package soon.
> 
> Fritz
> 
> Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev:
>> In regard to: [oi-dev] some Newbie questions, Friedrich Kink via
>> oi-dev...:
>>
>> Hello and welcom, Fritz!
>>
>>> reading silently for a couple of years this mailing list I decided
>>> now to contribute to the community my extensions I made over the
>>> years to my system (at least I'd like to try ;-)). The main purpose
>>> of my system is to act as mail server supporting all modern security
>>> features like DANE, SPF, DKIM, DMARC etc (which works btw for couple
>>> of years already, basically I started with opensolaris). That's why
>>> I'll focus on those packages. Of course I've some questions after
>>> starting this endeavor. Especially when trying to build Spamassassin
>>> which requires a lot of additional Perl modules. While start building
>>> these modules it turned out that the provided 64bit Perl version 5.24
>>> is pretty outdated. So I built the current stable version 5.34 based
>>> on the existing 5.24 setup. Worked like a charm ;-). Now first
>>> question: Is there a reason/dependency for not upgrading to a newer
>>> version?
>>
>> It's likely a combination of
>>
>> - limited contributor time
>> - contributor interest
>> - complexity of the task
>>
>> I do have an update to perl planned, but there are some details
>> to work out and I probably won't be back to looking at the perl modules
>> until I'm done with some MATE-related stuff.
>>
>>> Next question:  Some Perl modules have odd version like 1.04 which
>>> makes publishing a package impossible because of the padding zero in
>>> the number after the dot. What is the reason for bailing out on a
>>> padding zero (just a question for me and my understanding ;-))?
>>
>> That reason for that is probably documented in the documentation for pkg,
>>
>>     http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf
>>
>> though I would have to do some searching to find the exact section.  I
>> think it comes down to "design choice".
>>
>> As much as I like perl and have done lots of programming with it over
>> the years, its module numbering system leaves a lot to be desired.  The
>> standardization on "semantic versioning" that most other software has
>> done would be a welcome change in the perl module community, IMHO.  That,
>> of course, will never happen, but it sure would be nice if it did.
>>
>>> Also, some packages will require a new user and/or group. Are
>>> uids/gids managed centrally or can I just choose some numbers <100
>>> not used to my best knowledge?
>>
>> There is a file in oi-userland that documents the reserved IDs:
>>
>>     https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/reserved_uids_and_gids.md
>>
>>
>> If you need to add to that list, starting with a PR for that file is
>> probably the way to go.
>>
>>> How to store test results (I haven't found the trick where the
>>> results get stored in the test directory while comparing existing
>>> packages with mine).
>>
>> Create the test directory and within there create (touch)
>>
>>     results-32.master        # if your component has a 32 bit build
>>     results-64.master        # if your component has a 64 bit build
>>
>> there are other possible variants the file could be named, for special
>> build conditions.  Look through the test directories for the various
>> components in oi-userland to get an idea of other possibilities.
>>
>> Then, add various COMPONENT_TEST_TRANSFORMS to your Makefile, to filter
>> out any of the test output that will vary between build systems (PATHs,
>> timing, etc.).
>>
>> Once you have (empty) results files, the test target will start
>> outputting
>> diffs.  Incorporate the output into your results files until there are
>> no more diffs.
>>
>>> And finally when I think I'm ready to release my package would this
>>> list be the place to ask for integration?
>>
>> You can mention it here if you want, but following the "Building with
>> oi-userland" guide has a section on preparing your Github pull request
>> (PR).  Most of the component update work happens following that guide,
>> and the final integration piece comes via the pull request.
>>
>>     http://docs.openindiana.org/dev/userland/
>>
>> Tim
>>
>> _______________________________________________
>> oi-dev mailing list
>> oi-dev at openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
> 
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev