Contributed by pitrh on from the unkinking graphics dept.
Coming to p2k16, I had only vague plans what to work on. The last few hackathons I had tackled some projects that didn't quite result into something committable, so this time I decided to keep it basic. The idea was to update some ports and maybe make a dent in the use of the obsolete libiconv and gettext modules.
And that's what I more or less ended up doing, although I got quagmired in two ports in particular. The first was graphics/netpbm, a popular toolkit for image format conversion. A major new release of the "super stable" release series had appeared, providing years of improvements. Unfortunately, at the same time, it was still out of date by years and had not even caught up with the API changes in libpng 1.5. After manually merging a 900-line patch I had enough and decided that spending this much effort on code that was already obsolete did not make sense. We needed to bite the bullet and move to the "advanced" release series, i.e., the very latest releases, which brought in a lot more changes, including, finally, a regression testsuite. The downside of this is that upstream does not provide any tarballs and only makes the releases available in a SVN repository, so we will have to create our own distfiles each time the port is updated. I included a convenience target in the Makefile for this purpose.
While looking over the compiler and linker warnings, I also noticed that a lot of netpbm tools call srand(3) with optional seeds from the command line, so I moved everything to srand_deterministic(3). Despite the concerns of our esteemed project leader, many uses of random numbers do not need cryptographic quality (does it matter if the Space Invaders first zig and then zag, or vice versa?) and some applications specifically want, yes, deterministic pseudo-random data.
The other port that sucked up a lot more time than expected was x11/openmotif, the X11 widget toolkit. Again, a new release collecting a few years worth of fixes was the reason I started looking at the port. Figuring out what all our patches did took a while, and it became apparent that nobody had bothered in a long time. The existing port was a big pile of dung. Patches had been blindly cargo-culted forward for years. Some highlights: There were patches to fix the imake build infrastructure, which wasn't even used any longer. There were security patches that added checks that were already there, right in the context lines. There were patches to work around once missing functions that OpenBSD had had for years. The demo programs had been moved out of the directories that hold their support files and into the bin directory, apparently without noticing that many wouldn't run from there. By the time I had cleaned up the whole mess, I could as well have re-created the port from scratch.
As far as the cleanup of the libiconv and gettext modules was concerned, I made only a little progress. What is this about anyway? It all relates to, yes you guessed right, the removal of the vax architecture. Both libiconv and gettext provide a library as well as some support files that are read by the library. On archs with shared libraries this never was a problem. The whole package was installed as a dependency. On static archs, LIB_DEPENDS would turn into BUILD_DEPENDS: the library was linked in statically, no package dependency was installed. In order to provide the support files, a RUN_DEPENDS had to be declared. To unify the handling across both types of architectures, the libiconv and gettext MODULES were introduced as one of the very first uses of ports module. Now that there are no more static archs, this is no longer necessary and libiconv and gettext can be treated like any other regular dependency. The ports infrastructure has grown to byzantine complexity, and removing the use of the old modules means one less special case to remember.
All in all, the time spent at p2k16 produced some tangible if unspectacular results, and I had the chance to meet some new people as well as old acquaintances and feel out Theo's real position (as opposed to his devil's advocate online persona) on certain issues.
Thanks for the report and the work, Christian! We look forward to seeing those changes turn up on our mirrors real soon.
(Comments are closed)
By Blake (184.108.40.206) on 2112.net
After having gone through the same act a couple times, my default approach for upgrading stale, unmaintained ports has become getting the new version working first, then figure out how many of the old patches are still necessary...