From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from u2.inri ([107.191.125.208]) by pp; Mon May 11 18:01:16 EDT 2015 Date: Mon, 11 May 2015 18:00:44 -0400 From: sl@9front.org To: 9front@9front.org Subject: Re: [9front] pkg/unpkg strangeness Message-ID: List-ID: <9front.9front.org> X-Glyph: ➈ X-Bullshit: injection interface-aware hardware realtime-java locator MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > 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