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 [email protected]: > 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 >> [email protected] >> https://openindiana.org/mailman/listinfo/oi-dev > > _______________________________________________ > oi-dev mailing list > [email protected] > https://openindiana.org/mailman/listinfo/oi-dev _______________________________________________ oi-dev mailing list [email protected] https://openindiana.org/mailman/listinfo/oi-dev
