What pkgsrc needs most

Amitai Schlair

The NetBSD Project

Where's agc@?

Where's AGC?

"Al's Gargantuan Catalog":

  1. What pkgsrc does well
  2. How and when it got that way
  3. What we wish pkgsrc did better

The point of this talk

Make agc@'s AGC obsolete.

Make agc@'s AGC obsolete.

Make agc@'s AGC actionable.

Not as much new this year: Reasons (1)

Not as much new this year: Reasons (2)

Complicated code

Not as much new this year: Reasons (3)

Change-resistant code

Not as much new this year: Reasons (4)

Unclear, undescribed code

joerg@ seems to do okay

But what about the rest of us?

How do we get pkgsrc unstuck?

Fun ideas (1): completely unhelpful

Fun ideas (2): somewhat helpful

Fun ideas (3): my idea

My very specific one idea

  1. Let's write automated tests for pkgsrc internals.
  2. ...
  3. $ pkg_profit                 # !

Automated tests for pkgsrc internals?

But it doesn't matter what they're called, it matters that they're called.

Why tests?

A spec that runs

Why automated tests?

Hang on, I've heard this somewhere before

Part of the build

TEST_TARGET for individual packages. What about pkgsrc itself?

More implementation details

The one thing pkgsrc needs most

If we make it easier to work on, pkgsrc will get better faster.

If we work on this together, it will get easier sooner.

Hackathon weekend soon!

FIN

Questions?