hpr-knowledge-base/hpr_transcripts/hpr0876.txt

Episode: 876
Title: HPR0876: Packaging applications: BSD ports
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0876/hpr0876.mp3
Transcribed: 2025-10-08 03:56:23

---

Hi everyone this is Klaatu and this is HackerPublic Radio. This is the third episode in my how
to make Linux and Unixi packages, mini-series. In the first episode we covered Slack builds.
In the second we covered RPMs and in this episode we're going to be covering BSD ports.
I want to emphasize before we jump into the wonderful world of ports that I have only packaged three formats.
And that is of course Slack builds, RPMs and ports. So the fact that I'm not covering for instance a
portage or .debs or AURs or any other format that might exist doesn't really mean that I'm not
impressed with those formats or that I don't believe that they're significant or anything like that.
I simply don't have any experience with them and if I waited until I had experience with every single package format out there,
this mini-series would probably never exist. So that's why I'm doing this particular set.
Now why I am doing yes please. Yes please of course if you haven't heard the other two episodes.
Yes please is SIGFLUPS little application from the command line that takes a screenshot of your desktop
and uploads it to UnixPorn.com. Remember it's not porn it's Unix.
The reason that we're doing the packages for yes please is because well that's the only package I've
packaged on all three formats. But it's also a great little application and it's a great application
to package because it's a really simple compile. Like technically speaking it's just a .slash configure,
make and then make install. But there are some things about it that make it just unique enough.
For instance SIGFLUPS named the package a non-standardized name. It's not yes please dash version number
.compression it's yes please underscore version .compression. Secondly there are just a couple of little dependencies
and it's not necessarily a big dependency where you need just you know this one application.
It's an application and the development header files for that application for that library.
So that makes it interesting. And finally it's neat because her make file references and install shell script
I don't know where the shell script comes from but it's an install script that kind of grabs some variables
from being issued and so it seems to have so far broken all three of the packaging formats
that have attempted to package and wrap it up into its own little format.
So basically we have to kind of hack around the fact that her make file wants to call this install script.
So it's a really fun package to package and it's just hard enough to make it interesting and still easy enough
to make it a very reasonable starting point. So you should grab the port I'll include the link in the show notes
and it's simply called yes please dash port .zip. And if you unzip that then it will decompress to yes please dash port.
And that's pretty much the only that's that's the environment I I used to make this port.
I didn't really set up a big fancy port environment although of course naturally there will be a slash usr slash ports directory
that this ultimately goes into and then some I think it would be probably the graphics category within the ports tree.
For this you'll probably want to get something that uses ports or just listen along but if you don't have a computer running BSD
then you can again just do a really simple Qemoo virtual machine install free BSD.
It doesn't matter if you have a graphical environment it's not going to actually require that.
You'll obviously need to install graphical elements like libx11 but you don't need to actually be running it in order to see this build work.
When you install free BSD you will want to make sure that you're installing the port tree which does not come along by default.
And you can grab the port tree during install or afterwards like if you forget then you can always launch sys install sys in STAL
and that brings you up into a little incurses menu based application and you can select the distributions selection.
Go into distributions and there you will see the option to install the port tree.
And install the port tree it will be on the DVD if you got the DVD of free BSD it will be online if you got some minimal install.
Either way it's pulling down all the descriptions of all the port files that exist.
So it's not pulling the source code it's just pulling text files that talk about the source code.
If you've ever used slackware in particular chess griffons very very cool SBO pkg application then this will sound really really familiar to you.
It actually does the same thing. It rsinks to the slack build server.
Grab all the text files about the slack builds and then the slack builds themselves but it grabs those.
And then when you run it it goes out and grabs the source file the source code and pulls it down to your computer and then builds it and installs it.
That's exactly what ports does or I guess I should say the other way around.
Ports does that and SBO pkg emulates it.
So presumably by now if you've been listening to me you probably had time to install free BSD there during the interim because it's a really quick install.
Then you'll have free BSD in a virtual machine or on your computer and you'll probably also have yes please dash port.zip and you'll have unzipped that and then will be inside of the yes please dash port folder.
If you do an LS you will see four files. At first glance I'll bet you're thinking this looks exactly like a slack build folder.
And yeah it does. It looks really familiar.
So stepping through them this is also going to sound quite familiar. Do less on dist info. Well there's dist info and it's the MD5 sum of the source file.
There it is. And there's the SHA 256 sum or hash of the source file.
And then finally there's the size in in bytes of the source folder or the source file rather. That's obviously really important for verifying that when you download the source code for yes please you're actually downloading the source code for yes please.
Next file in the process is the make file. We are going to skip the make file this moment because that's the big one that we're going to talk about and it would be weird to start talking about that and not touch on these small ones first.
So let's do a less on package description instead PKG dash DESC. Yes again that is DESCR. Again that is almost exactly the same as the slack desk file in the slack build.
And sure enough it is basically the same as a brief description of the application and then at the bottom it's a fairly common to give the home page of that of that application.
So people can go there, check it out, see what they're getting into, stuff like that. And that's pre-painted with WWW colon space and then the home page.
So that's a package description or DESCR and then finally the package dash P list which is very very very similar to the RPM the very bottom of the RPM file where you have the percent sign files and it kind of describes what exactly you're going to make its way into the RPM package once it's built.
That's basically what this is. The package P list is a laundry list of all the files that need to end up in that port document or in that port file rather.
So when you're doing a large application for this port process and if you're doing something very complex this package dash P list could get pretty involved because it literally is a list of all the files that this port is going to install.
And it needs to be complete. So be sure that you know exactly what's happening during the install process. The only clue that I have how you would do that on a very very large application is to do a make dash dash dry run or I should say dash dash dry dash run and that does the make processes if though it was making but it doesn't actually make it and you can kind of follow along and see what's getting what's going to be put where.
Another way that the portors handbook on the freeBSD documentation site says is to make the you you make depends and then you can look in the slash of our slash temp in that port name and find all the files there and cat a list of those files into a package P list both ways it seems pre involved to me and I don't have enough experience with serious ports.
You know beyond not that yes please is not a serious port but anything more complex than yes please I really have no experience with ports but I still think it's an interesting study of packaging anyway.
But yeah so the package P list can can get pretty complex if it's a really complex application so watch out for it. And then finally we can look at the make file.
Now make files I like a lot I I was using them for a while in my dog book workflow and I need to start using them again for other stuff because they're just really handy and and here's a make file now.
So the make file in the port folder is the thing that port is going to use to to actually build this thing so the equivalent therefore would be an rpm spec file or a slack build slack build file.
The header we've got the very official kind of BSD header that the Porter's handbook says that you should use if you're especially if you're going to submit this for inclusion in the actual port collection.
And then we set up some variables who I bet you would have never guessed we were going to do that at the top of the script.
Well yes we do it's port name equals yes please package name suffix and this is where we kind of had to hack around the naming scheme again I remember in my first attempt at this port.
I put org for 2010 as the version number because that's what I had to do in the slack build and the rpm I think and so I thought well surely it'll be the same trick here.
Nope it's a package name suffix and that's the org for 2010 now the port version is one so that's again kind of like a slack build version build and the rpm version.
So this is the port version one and obviously if I was packaging all these they would increment as I updated each each different one the port revision is zero because I haven't revised this at all.
Categories is graphics so if we were going to locate this yes please script on a BSD system like if this port was actually accepted into the official free BSD collection of ports we would go that we would find it at CDs space slash USR slash ports slash graphics slash yes please.
And then the master site is HTTP hobones dot dog soft dot net and the dis files is yes please underscore org underscore four underscore 2010 dot TGZ so you see that the whole download link did not go on to one line like it did in slack builds.
And I think probably rpm's I don't really remember but the dis files it's it's on the dis files the actual source code the master site is the place where it lives.
And then the work source is going to be a dollar sign curly bracket work there curly bracket slash yes please underscore org underscore four underscore 2010.
This sounds exactly like a build route in an rpm doesn't it or a temp folder in slack builds told you all of this stuff is basically the same after you kind of start looking at them.
It's it's they all need to do the same thing and there's only so many little variations you can make on getting to the same end result.
The maintainer is hey there I am again comment is a screen capture you till that also uploads the screenshot to unix porn dot com.
See I was trying to minimize the unix porn dot com thing there because I was feeling pretty guilty at this point of having packaged an application that clearly favors a site that I am a part of.
So I was trying to like oh yeah by the way it also uploads to unix porn not that I care about that or anything.
I don't think the bsd people fell for they didn't I don't think they've accepted this into their official distribution yet can you underscore configure equals yes all underscore target equals install.
That's simply saying that the end result of this build is going to be yes the install that is what we are doing for the make you know install.
Can you configure prefix is slash usr slash local because hey this is bsd and we don't put stuff in user been we put it in local like God intended because the thing about the local directory and even the slash opt is that originally in theory at least from what I've heard a unix distribution is a unix distribution there is the base system and everything that you install on top of that goes into slash usr slash local slash
slash you know share bin at see whatever and that's how it was and it really kind of divided up what you would install as opposed to what the system was as an installation and I really like that I like that kind of logic but I guess as as
as unix systems started coming off of the big big huge computers that that serviced entire universities I guess you know it kind of it all got kind of meshed in together and it's like well you know it's your personal computer I mean who cares if it's in user local or just user been well I care but and bsd cares but no one else does no underscore install underscore man pages equals yes I always like those kinds of positive negations
where you say do not install man pages yes and that's what we're doing here we're just saying that there are no man pages here and so we're not going to run any kind of process to hunt those man pages out and then install them and and that again that's one of those things that yes please kind of makes
really simple for us because there's no there is no documentation to speak of that's that's kind of nice and then we do a dot include space less than bsd dot port dot mk greater than sign and that is basically just like an
include in like a header file not that I even know what any of that means but it's it's it's a reference to another entity so it's a dot include to something called bsd dot port dot mk and that that bsd dot port dot mk is a file on the system in the
port tree that has a bunch of instructions on base I mean I kind of think of them as little macros or or almost another make file or a an install script because it's doing all the different things that are required for that
port to work for instance it's fetching or if you're a Linux user you might think of it as a w get it's it's it's grabbing those source files off of the internet as defined in your variables master site and dist files it is untarring them at some
point it is going to make sure that all the dependencies are there it's going to patch them if you had a patch included in your in your make file it will install them because we did say after all that the
all target was install different things like that so it's it's kind of like it is what RPM is doing in the background but in this case it's just another
it's a script that you can look at and kind of investigate on your own it's it's pretty neat it's I've looked through it once I didn't really dig that much deeper into it but it is it's very cool and it it reminds me very much again of slack builds just because it's all kind of written out right
there and kind of very obvious as to what's going on behind the scenes you may not include anything after the dot include bsd dot port dot mk line that's the end of your
file after that all of your variables have been defined all of the things that you want to have happened are now about to start
happening so you can't do anything after that it won't let no I never tried it but I'm assuming it won't work or if it does work it'll be horribly horribly broken in some
terrible subtle way that you won't notice until it's all too late so there you go that's that's a port file now to build a port
file you need to be root first of all so we'll be root and then you can move or at least what I did was I moved the s
please port folder to slash us r slash ports slash graphics remember that's where that's the category we
assigned it and then you just drop it in there as yes please don't don't keep the name yes please dash port just call it
yes please okay so now it's in the us r slash ports and now we'll change directory ourselves into slash us r
slash ports slash graphics slash yes please and now you may do a make install clean and that will run make
install and then after that's finished it will run clean and the make install obviously looks at the make
file for instructions the target that we're making is the install target which is well the it's established
that that's our target in our make file and then they the install target itself is defined in that BSD.port.nk file or thereabouts
and so it runs the compilation process and it installs it onto the system and that's it you're done you've
made a port file now and you can do an uninstall of it just in the same way and and just like
any on any other system it has it's keeping track of what has been installed all the different files the file
list remember that pkg-p list file that's got a list of all the files installed in the system so when you do an
uninstall it knows exactly what it needs to go out go out and hunt and get off of your system so
that you then have a system that it looks like yes please has never touched and it's really that easy
to do a port so I don't know the more you do packaging the more they seem at least so far my limited
experience the more they seem all pretty much the same and while you might think while there are so many
packaging formats in in this whole Linux and Unix realm and it's just gets so confusing
um it is and it isn't there's there are a lot of packaging formats that probably some people
like their packaging format better simply out of sanctimony and and probably other people
really do think that their format is is better or easier to use more flexible I don't know whatever
everyone seems to have either their favorite packaging format or they're just kind of ambivalent
toward it and they're just like well hey whatever distribution I'm running whatever they tell me to grab
that's what I'm going to go grab I don't think it tends to be that much of a problem to the actual
user until you need that RPM out there and then you go to look for it and it doesn't exist
they've only got a dot-deb and a dot-exe you know and you feel left out of course
there are things they're converters like alien alien can convert between Debb and RPM and
Debb that seems pretty useful but obviously for the really complex ones that have lots of
hacks or lots of dependencies and all the dependencies are named something different on
each system you know it can get it can get kind of confusing there's even an RPM to TGZ
script on a slackware system so if you can find the RPM and you wanted a slack build
you can actually convert the RPM to a slack build and that'll work pretty nicely
so there are ways around it there are other periphery packages that I don't
really use that much but they exist they're perfectly valid and they might be in some
ways better than others but I happen to like the slackware method and in free
software one of the big deals about running free software is that we can each
have our preference we don't have to all have the same kind of packaging format
we don't have to have all the same distribution or anything like that.
The flip side of that argument obviously is that there's strength in unification
and that if there is every Linux and Unix user is using you know RPM then
that will enable corporations to then distribute things in an RPM format
and then they might be encouraged to do that because when they're looking at their
build process they can say yeah well we're going to make this package for Mac OS with
GCC anyway we're going to make this one for windows on whatever that uses
and we can make one Linux package that's an RPM and we'll be able to rest assured
that every Linux user out there will be able to utilize this and G isn't that great.
Now in reality I wonder if this would actually persuade them to do that or not
anyway I don't think companies that aren't terribly unix and Linux friendly
or even like aware maybe it's not even actively unfriendly it's just they're not really
they're kind of clueless I don't know that just because we had one packaging
format that had the big stamp of approval if that would inspire them to go ahead
and distribute their application in the RPM format it might it might not
we we don't know the great thing about knowing packaging or at least being familiar
with it is that if you do find a piece of source code or a collection of source
code that you want on your system and you don't want to compile it from source
in such a way that you cannot later extract it you can package it up for yourself
and so if you know how to do a Slack build or an RPM or a port or a .deb or whatever
then if you if it's an application that you want and you know that you're going to
use for a long time in the future package it up once it's packaged you'd be amazed
had how easy the maintaining the maintenance of that package really is
they're very smart formats they have variables they have version numbers
and they've got preset conventions and even like little cheats and tools
that you can use you know I mean it's not like you actually have to write the code
to detect your architecture every time in a Slack build that exists so you can just
copy and paste it you don't have to write the prep step or the install steps every
time in an RPM they're little macros for that they will do that stuff for you
and in ports you've got the bsd.port.nk file you don't have to do a whole lot there
you simply are defining your variables setting up your building environment
and especially if you are sticking with one distribution
with as your main computer there's not going to be a whole lot of variation there either
if you're on bsd you know that your prefix is going to be usr slash local
if you're on Slackware or Fedora or Red Hat whatever it's going to be slash usr
so there's a lot of stuff that from the outside it looks very complex and chaotic
and a little bit foreboding but once you understand the process
it's actually not that big of a deal and even if you can find an RPM for instance
for an older version of something and you really really want the new version
there's really nothing stopping you from extracting that spec file from that RPM
modifying it dropping the source code into an RPM development environment
creating a new RPM for that you've got a package for yourself
put it on a backup drive and you've got it for the next time you are installing a new computer
on someone's machine and they want that application or whatever the case is
there are Slack builds and config files and little cheats for easy installs
that I carry around with me all the time whether it's for public in or EMAX
or for well yes please you know any of these little applications that I use on a day-to-day basis
I've got my own versions of these installers or these configs or whatever
and all I have to do is go in and tweak like one number every what year
whenever I reinstall Slackware I mean it's just it's not that big of a deal
so the packaging issue might not be as big of an issue as you might imagine
as long as you have a little bit of an understanding of how it all works
and as long as you take hold of the sense of empowerment that Unix and Linux brings us as users
because it's all free software we can do this kind of stuff for ourselves
we can make it how we want it to be and that even goes down to the really complex stuff
like packaging up applications so give it a shot
play around with it on whatever distribution you might be
I'm sorry if I didn't include your package format in my little mini series
again it wasn't because I don't like it or or anything like that
because I don't think it's as good as the others it's just that those happen to be formats that I
I wasn't using whenever I sat down and finally figured out how to
package up an application that doesn't mean I'm not going to learn in the future
simply means that at this moment I do not know it but they're all really fun
and I do encourage you to to give them a try and share them with people if you want
of course I'll read your code very carefully before I go installing it on my computer
but you know feel free to share
thanks for listening to Hacker Public Radio
this has been the how to package applications for Linux and Unix
episode or mini series rather and this is the conclusion so thank you for listening
you have been listening to Hacker Public Radio or Hacker Public Radio
does our we are a community podcast network that releases shows every week
day Monday through Friday today's show like all our shows was contributed by
a HBR listener by yourself if you ever consider recording a podcast
then visit our website to find out how easy it really is
Hacker Public Radio was founded by the digital dot-pound and new
phenomenon computer cloud HBR is funded by the binary revolution
at binref.com all binref projects are crowd sponsored by linear pages
from shared hosting to custom private clouds go to lunar pages.com for all your hosting needs
unless otherwise stasis today's show is released under a creative comments
attribution share alike read us our license