Initial commit: HPR Knowledge Base MCP Server
- MCP server with stdio transport for local use - Search episodes, transcripts, hosts, and series - 4,511 episodes with metadata and transcripts - Data loader with in-memory JSON storage 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
223
hpr_transcripts/hpr0876.txt
Normal file
223
hpr_transcripts/hpr0876.txt
Normal file
@@ -0,0 +1,223 @@
|
||||
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
|
||||
Reference in New Issue
Block a user