Introduction
- Q: How can I get involved in infrastructure development?
- A: Get your feet wet by doing small projects!
- Opportunity to become more familiar with the various interrelated frameworks in pkgsrc.
libtool
- devel/libtool should install the script as glibtool"
- avoids problems on Darwin which has it's own /usr/bin/libtool that's not GNU libtool
- No impact within packages:
- glibtool would be symlinked into ${WRKSRC} package libtool scripts at post-configure time
- packages that don't have their own libtool scripts invoke ${LIBTOOL}.
- Very easy!
Regression Tests
- PATH variables are very important in all of the pkgsrc frameworks.
- Strong reliance on calling wrapper scripts instead of the real thing
- Write regression tests that verify the PATH is correct in each phase.
- Very easy!
Patches
- After a patch is applied, write the name of the patch and also its checksum into the patch cookie.
- Useful debugging information on which patches have been applied if a package breaks
- Modify do-patch target to write the information into a temp file under ${WRKDIR}.
- Modify patch-cookie target to move the temp file to ${PATCH_COOKIE}.
- Very easy!
Perl
- Change pkgsrc convention of where pkgsrc p5-* modules are installed
- Use the "vendor" directories instead of "site" directories"
- Vendor directories are never touched by the Perl distribution.
- Site directories would be untouched by pkgsrc, so users can put local modules there.
Perl (cont.)
- Modify lang/perl58/patches/patch-ah to change precedence to SITE*, VENDOR*, ARCH*, PRIV*.
- SITE* comes first so the user can install modules to override pkgsrc for site customization
- Modify lang/perl5/module.mk to install modules into vendor directories.
- Modify lang/perl5/vars.mk to generate PERL5_VENDOR* variables instead of PERL5_SITE* variables.
- PKGREVISION bump on every package that depends on perl directly or indirectly