Re: [9front] pkg/unpkg strangeness

[sl@9front.org]

> imo, unpkg should be rewritten in rc.

For what it's worth:

I was never happy with pkg(1) as the result of our early discussions
about creating a ports system.

My original suggestion was something more like what OpenBSD does: We
would maintain (only) mkfiles that include targets for download, hash,
patch, install, uninstall, etc., and not bother with the rest.  This
got lost in the discussion with other participants.  We ended up with
an initial pkg(1) system that distributed binaries and at first didn't
even include the source files used to build the package.

There are other quirks.  For example, pkg(1)'s rc scripts get
installed into /$objtype/pkg.

The original author vanished and I've ended up maintaining the package
repository as well as doing a generally poor job adding small
features, like including the source files in the packages.  It's not
entirely clear to me why unkpg is a c program in the first place.

Recently, there has been talk again on IRC about creating yet another
ports system.  I took this opportunity to once again advocate for a
simple set of conventions for using mkfiles.  Someone else suggested
what I thought was a good idea: Install each package (source and
binaries) into its own root under some arbitrary package directory and
then bind the needed files into place.  A mkfile target could print
the needed bind commands.  This would completely eliminate the need to
invent any new mechanism to track installed files.  To see what's
installed, use ls.  To uninstall, use rm.

That said, I'm no longer in favor of any kind of ports system at all.
This stuff always boils down to a lot of arguing and coordination and
bookkeeping without much real benefit.

sl