June 01, 2016 posted by Kamil Rytarowski
The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.
The NetBSD team has prepared series of interviews with the authors. The 2nd one is with Sevan Janiyan, a developer well known for his bulk builds for several platforms.
Hi Sevan, please introduce yourself.
I'm Sevan Janiyan. A sysadmin from England and a NetBSD developer,
working on the pkgsrc packaging system. My areas of focus are pkgsrc
security and Darwin (PowerPC) but as I enjoy running many operating
systems I manage builds on a variety of them across different CPU
architectures. I was a user of pkgsrc for many years but only started
working on pkgsrc itself early 2014 when I obtained a PowerBook from a
friend and started fixing issues on OS X Tiger/PowerPC. I was invited to
become a member of TNF in 2015.
First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?
It's fantastic to see a tool that has evolved over time, it's extremely
flexible and has grown support for numerous operating systems during
this period. Not only can it serve as the native packaging system for
most OS' but thanks to its multi platform support, it can be used to
save a lot of effort in implementing a packaging system on a project
when a set of packages need to be built and deployed in a consistent
manner across multiple operating systems.
What are the main benefits of the pkgsrc system?
The ability the provide a single API for dealing with multiple
environments & toolchains, for example translating a setting to the
relevant flags to compliment the compiler in use.
Unprivileged mode allows a user to build the tools they require in a
location which executables are permitted and the user has write access
e.g your home directory when the partition it resides on is not mounted
The buildlink framework - it provides the ability to detect components
available on the host operating system & allows a user the choice
whether to build against such a component or to opt for a version
provided by pkgsrc itself.
Where and how do you use pkgsrc?
pkgsrc is an essential part of my sysadmin tool belt, on one hand I rely
on it to obtain a set of packages on a system without touching the
systems packaging system. This is for example on a customer system where
I either have not been given root access or I do not wish to install a
package on a system with a big dependency list for my personal use.
The packages in pkgsrc generally see very little in terms of local
changes, besides tweaks to ensure package integrates into the system.
This encourages interaction from developers with projects to upstream
changes. This can be a benefit when debugging software issues where it
is not certain if the issue exists in the version of software package
from OS vendor or there is a bug in the software project upstream.
The ability to bootstrap multiple instances of the packaging system under
different prefixes permits a user to install multiple and conflicting
versions of software in isolated locations on a system.
As a use case, I worked on a project troubleshooting a clients varnish
instance. The issues they were experiencing was specific to the version
packaged for their OS by vendor. This was varnish 3.x and 4.1.0 had just
been released, we decided to evaluate varnish 4.1.0 but as there were
changes to the configuration language some development would need to by
carried out, to adapt things to the new syntax. To reduce downtime the
instance of varnish installed using the native package manager was left
untouched and continued running, pkgsrc was bootstrapped in a separate
location and varnish was installed from there.
The development work to bring the config up to date happened with the
new version of varnish from pkgsrc listening on a different port, but
running alongside the original 3.x instance. Switching between the two
instances was just a matter of changing ports to forward traffic to on
the front-end web servers. Unfortunately 4.1.0 release had some bugs,
so we considered trying 4.0.x. Another instance of pkgsrc was
bootstrapped & v4.0.x was installed, again running on another port. This
instance was brought up alongside the other two instance and started
receiving traffic, at this point it was trivial to evaluate behaviour
across 3 different versions of a piece of software running on a single host.
What are the pkgsrc projects you are currently working on?
I've worked very little in the tree recently. I continue to run the bulk
builds of pkgsrc-current on a variety of systems and have recently begun
making the packages generated from some of these builds for people to be
able evaluate pkgsrc. At present there are packages for OS X Tiger
(PowerPC), Debian Linux (amd64 & armv7), FreeBSD (amd64) and OmniOS
published on https://files.venture37.com/pkgsrc/packages
If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?
A better mechanism for running the bulkbuilds or to grok how to setup
the parallel builds.
Do you have any practical tips to share with the pkgsrc users?
As I mentioned with the varnish example, you can save a considerable
amount of effort when required to run multiple instances of conflicting
components by using pkgsrc. As everything isolated to a given prefix,
specified during bootstrap, it's trivial to run multiple versions of Ruby
for example without any conflict.
You can leverage this to experiment with changes which could be deemed
volatile using other means.
What's the best way to start contributing to pkgsrc and what needs to be done?
Pick an OS from list, try to bootstrap pkgsrc on it, try to install some
packages. If the process failed at any stage, file a bug report even
better if the report includes a patch.
Rinse, repeat :-)
If you have resources to attempt larger builds, follow the steps to
setup a bulk build environment and run a build. The results ideally
should be published on a public webserver & the report posted to the
pkgsrc-bulk list, developers and maintainers use these reports to see
problems and it could serve as a starting point for a potential
contributor as a list of things that need to be fixed.
Bulktracker also makes use of these reports to build a picture of the
status of packages and their impact across multiple platforms.
Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?
Yes, see you there