Jac Steiner <jackrsteiner%gmail.com@localhost> writes: > I'm using pkgin on OS X 10.11.4. There are some packages that I'd like to > try to make work on OS X. I understand this might be too big of a project > to start with, but is there low hanging fruit that someone could point me > toward. Sure, more help is always welcome. The first thing to understand is the overall flow: pkgsrc is a set of source files managed in CVS on a netbsd.org server it contains control files that describe how to build packages people build binary packages from these control files and make them available pkgin updates packages based on some set of binary packages So, I think what you want is to either add some packages or to make packges work on OSX that don't know. > My initial interest came when I found I couldn't install gptfdisk or vlc > with pkgin. Gptfdisk I think is not included for any OS that pkgin works > with, but looks like an easy win, I think. While vlc can be installed on > other OS's with pkgin, some preliminary experimenting suggests to me that > GUI dependent pkgs don’t build or sometimes don’t work on OS X with pkgsrc. > Obviously, both apps can be built on OS X, or installed from pre-packaged > binaries, but it’d be fun to get things like this to “just work” with > pkgin. Where do I get started? There are various reasons things don't build on OS X; it's almost normal UNIX, but not quite. > The recommended process (https://pkgsrc.joyent.com/docs/building/) for > building packages with pkgsrc starts with cloning the entire git repo from > github.com/joyent/pkgsrc.git. I think this repo includes much more than > just what I need to start packaging, but I'm honestly not clear about that. > Is there a more lean base to start with or is this the way to go? I’m > dealing with bandwidth limitations (in Micronesia). Also, I’m a bit > confused. If I want to bundle packages for pkgin, isn’t there some package > I can install with “pkgin in” to help me do this? pkgsrc is in CVS, and that git repo is a clone more or less. However, it should be a good basis to submit changes against. There is also pkgsrc-wip, which is a good place for entirely new packages. With pkgsrc, you'll need a fair bit of the sources to build anything (mk/, perhaps some things in pkgtools, various buildlink3 files). I would recommend getting the entire checkout. This is just control files, not distfiles, so it's not really that huge. But with a thin pipe, it could be awkward. Using git and a shallow clone might help. How small is your pipe? I used to update pkgsrc cvs over a 28.8 kb/s modem. It might have taken all night, but I just let it run. With git, once you've gotten the first clone, updates should be fairly small. Keep in mind that mixing source builds and binary packages works fine, but only if the source tree and the tree used to build the binaries is the same. > I want to use the most standard way of doing this, observant of best > practices, particularly regarding portability. Basically, either add a new package in wip, or submit a patch against pkgsrc HEAD. While your goal is a package that works with pkgin, your work to make the package build won't have anything to do with pkgin. When editing a package, keep in mind that it should build on many operating systems, versions of those operating systems, and CPUs. So just adjusting the PLIST to match what happens on your system is usually wrong. There is a lot of conditional logic. Read through this, keeping in mind that it's incomplete: https://www.netbsd.org/docs/pkgsrc/ Enable PKG_DEVELOPER=yes in mk.conf. When you get stuck, ask. It's really hard to give abstract advice, but if you have a package that almost works with some problem, others can usually point you in the right direction quickly.
Attachment:
signature.asc
Description: PGP signature