I can hear myself pretty good. I guess you guys can hear me too, right? All right. Excellent. And so today I'm going to be talking about different features that package source has. And I assume all of you are familiar with either package source, free BSD ports, or open BSD ports,

or some other packaging system like that. And so today my focus is on package source, but we'll talk about some things that might be different, or you'll see it's different between the other package systems. We're going to talk about its portability and some of its goals. One thing to note is package source is maintained by NetBSD,

but it is certainly not NetBSD specific as we get later on. I only list a few operating systems on here. Later slides show a lot more. I should have at least listed Mac OS 10, for example,

or something on here, but it's not official. Like these other ones, package source is a little more official. Just to give you some background, I've been using package source for a long time, and it's how I became a NetBSD committer. I probably submitted 50 plus problem reports,

and maybe 50 packages or so. And so then I was able to be invited to commit right to the package source tree because I committed so much work. Some of the work I've done with package source,

I did work professionally for a medical research company, and they had a variety of different software that there was no packages for, and their Mac OS was their platform. And so I just did work porting a lot of their dependencies over to package source.

And a lot of their software did not get put into the package source tree, but I had to make sure that all their dependencies worked correctly on a Mac OS platform for them. Also, as a consultant, I did a lot of work with BSD OS. And basically, these systems were dying,

but my customers had to keep on using them because they had commercial software, and they didn't have any schedule to migrate to a different platform. And so I used package source even for several years to continue to maintain the software on their system, production software.

Also package source, I packaged up everything that was essential to a Linux distro, including the kernel, glibc, modutils. Everything that wasn't in package source already, I did that for Linux. And then I made a 100% buildable system

using all package source. And it was sort of fun, and it also helped me see edge cases, I guess, in package source, especially with installing directly to slash user, for example, in trying to make sure that software didn't depend on the wrong things as I built it.

I've created hundreds of packages, and I look into my package source new directory. That's where I start my work, and I see, oh, man, I have like 150 packages in here, and try to get those all pushed upstream.

And I've maintained certainly hundreds of others. I've touched certainly thousands of packages in one way or another. And also providing bug fixes and improvements to upstream projects. If we make a change, and I'll talk about it later, but surely share these with upstream developers.

Package source for several years has had a weak little rotation. I've been slacking off a lot this last year, but I've participated in that for several years. And basically, you watch PRs or problem reports that come in, and we do triage for them. If they're trivial, maybe we'll fix them ourselves, or we'll ask another developer

if they'll take that ticket, or we'll get feedback for asking for more information, or we'll automatically assign it to somebody. But it's good to do a little triage for the ticketing system. Very quick intro. Of course, package source is two different things.

It's a software build framework. It does many, many things, but the very basics of fetching and verifying what it fetched. Maybe a configure step, a build step, the installation and packaging step, and then install again. You can see I have this reverse package and install. Maybe we'll talk about that later. I'll do a staging.

Also, it's a software installation management system. Installing, upgrading, configuring software, removing packages in a consistent manner. A package source does not have to be a build-only system. I have several systems where I do not have a package source tree. I just use the binary tools to install and maintain

binary packages. And so it's certainly doable. Quick history. So FreeBSD won in 1993. It included some of the tar sets included source for many of the popular software.

In 1995, those source sets were put into an infrastructure which they called ports. And you can see it's the same description as it is today. Go into the directory you wish to install, type Mac make, and let the system do the rest.

Package source now was forked in 1997. As you can see this quote here, maybe the person in this room said this quote. I'm not sure. But try to keep things in sync with FreeBSD ports. But as you can imagine, two different systems, different goals, and it diverged.

This is really interesting here. Within a couple of years, ported to Solaris. Very useful. Then again, ported to Linux. And the bootstrap support done very shortly after and then

imported to the tree. And we'll talk about this. We'll have some slides right about it. But it's basically so you can get package source up and running on a different system like Solaris or Linux. All right. Got cut off here. But the gist of it, there's different ways to get package source.

One way is you could check out the package source via CVS. Or you could fetch a tarball, whether it's bzip, gzip. Or you can see this one, xz. This tarball right here, as of today, is around 24 megabytes.

But I think I might be off. But when you extract it, I think it's around 700 or 750 megabytes. It's a lot. So what's extracted, of course, is all the specification files. But also, it has some source code also. And those are things that are key for bootstrapping.

Then, of course, it also has the infrastructure, makefile snippets, for example. Let's talk about the bootstrapping. The bootstrapping is portable. There's shell scripts and makefiles for building and installing the dependencies in the packaging framework tools. This is portable, so we'd be able to use it on various

different operating systems. A few things that are key. It uses net BSD's make, which is a derivative of pmake. You cannot use free BSD's make or open BSD's make or Dragonfly's make. Just some slight differences.

And also, it installs the package install suite, which is the low-level commands like package delete, package info, package add. It may use the net BSD compatibility shim. This is a library providing definitions and functions missing from other platforms.

Provides some BSD-isms that you might have lacking on a Linux box, for example. Package install uses libarchive. It can stream different types of archive formats. And so that's a portable project.

And depending on your system, there might be a few other things that need to be bootstrapped. A simple install script, a knock, net BSD's version of sed, and the public domain kshell. It's because some systems might have a broken shell,

for example, or they might have an awk that's just incompatible or a sed that's incompatible. So we can bootstrap and get some of these included. There's other dependencies also, but they're not critical for the bootstrapping part, and they will be installed later on once you

start installing software. For example, digest for checking the hashes for verification. TNFTP. By default, most of them need some way to fetch the software. So net BSD's FTP also has an HTTP client.

And also some patch versions are broken. And hopefully I don't need water. And so net BSD's version of patch. Supporting net BSD is not the major goal. And there is software in the package source tree

that is not ported to net BSD and probably never will be. And so package source is a way to install third-party software, and in some cases, that software. Nobody in net BSD wants to use it, but somebody that uses package source will want to use it. Of course, if it does support net BSD,

then you should make sure that it at least builds there and installs there. But it's not the major goal. Many architectures, multiple versions of operating systems. They might have different headers, of course, different system libraries. Even different compilers and different build tools. And so we're not tied down to many different things.

And so that's pretty nice. So this is an important point. When we need to port a software over, let's say, to net BSD, we're not going to first specifically just patch it for net BSD. We're going to abstract it.

We're going to look at it from a bigger point of view. If it's looking for this feature, then we'll work and make it patched for that feature. We're not going to patch it specifically for net BSD. Or the same thing if we're porting it over to Darwin or Mac OS. We try to do it the most generic, a proper way. A way that we could share it to the upstream, and they can commit it to their upstream code

without breaking their own software. I've seen other port systems where the patches are specific for their operating system. Not trying to pick on FreeBSD or OpenBSD, but very specific to them. They cannot share their patch upstream verbatim because it's specific to their operating system.

So that's an important point. And so we share these patches back as much as we can. All right, platform supported. One thing to note is some of these platforms were done years ago. And it's possible that there's some people that don't use them anymore. Or if they use them, they're not updating their package source tree.

They might be out of maintenance. I could use BSDOS as an example there. I heavily used it, but I have not tested it. I've tested it this decade. I haven't tested it maybe two years or so. So reasonably recent. A few things to point out here.

In fact, some operating systems I don't even know. Freeman, for example. But Mac OS X, there is a package source developer that maintains binary packages for Mac OS X. And so and hosted via his company, I think Joyant. Some of these will use a package source right now

as their main third party software packaging system. For example, Dragonfly. And so the list continues. Linux, that's sort of generic. But I've used it on CentOS, Red Hat, Debian.

I know others use it on Slackware. I've used it on a variety of different Linux systems. Minix 3 package source is sort of their main suggested way to install third party software. Also, Joyant provides packages for smart OS, I believe.

But you can see right here a lot of different platforms. And we can bootstrap and be able to install third party software easily on different systems. And so that's one of the main strengths. And it separates package source, as far as we know, from almost any other packaging system.

There's a few other package systems that have been made that work with FreeBSD and Linux and maybe Solaris. But they don't have such a huge team of developers maintaining them. And so package source truly is the most portable.

We have a large number of packages working with the same code base. So you have a portable uniform operation over different systems. And so if you learn how to install the software on one system, the layout of how it's installed, the way the configurations are by default,

how you're going to start and stop things might vary a little bit. But we do install the same start stop scripts. And so it's a really portable uniform operation. Also, you might have specific patches, for example. And so having those specific patches portable across all your systems also as an admin.

So I already mentioned some of that. And also the same things with the same build options between different systems. One thing to note is with various configuration files,

by default, it puts these configuration files in examples directory. This is very useful for administrator. And you're going from system to system to be able to see the original suggested configurations, which might be suggested by the package source maintainer. Or they might be the suggestions directly from the mainstream.

But we install those. On installation, we don't overwrite the originals. And on de-installation, it has a simple way to look at examples version. And if it's changed or not, you can know if it can remove your old configuration or not. And these things are a little bit tunable. And there's messages telling you about this.

Over the next many slides, we'll just talk very briefly about many of the different features that package source has. And it does so many different things. And most people don't use all the different features. Where you can see the examples here, by default, where the configurations go.

If you're running an unprivileged mode, which I'll talk about later, it can go in your home directory like that or a user package ETC. But you can change or you can tune where your configurations go. Maybe your site has a policy of where you need to install, or maybe because of your backups, or you have some reason.

And so you can change it to install directly underneath the ETC directory, for example, or under a subdirectory, ETC-PKG. Or if you need to get really fine-tuned for specific software, if they have configurations, you could have a setting that you

could set for every single software to go somewhere specific on your file system. So it's pretty fine-tuned that way also. Of course, in these last two cases, you would need to rebuild or reinstall those packages after you made those changes. This is another awesome feature. And so as a user, as a sysadmin, and as a developer,

there's many cases where the main Unix system, I cannot touch its standard packages. Maybe they're maintained by a different operator, or I don't want to break things for other developers. I mean, I can't upgrade their versions of their libraries

for the system. And so what I could do is I could do builds as a regular user and just dump them into my own home. This is very convenient. And so first of all, the package source, in most cases, users and groups, are very well abstracted for different software.

And so package source can customize this. They can create these users and groups as needed. And because it's so well abstracted, you don't have to have many different users and groups. You could just use your own user account, your own group account. And so that's very nice. And you can see the bootstrap command.

It has a switch called unprivileged. And by default, it'll set the prefix so it'll all go underneath your home, underneath a directory called PKG. Oh, a couple of things to point out. So the first time you're bootstrapping, you have a big tarball to unextract. And then you bootstrap it, and it takes a few minutes.

And then you start installing software. The first times you're installing software, you might have many dependencies installed. And so yes, it's installing a lot of clutter that you may not think you need. But after that, when you need to install something, it should be quick and simple, painless. As you can imagine, multiple users on the same system

could install their own packages. Hopefully, your system's fast enough. Or not only that, with little tweaks, you could install multiple package source installs on your system in different locations also. I'm going to talk about that briefly later.

This slide, I should ignore. But I will have to say, there's problems in any system. And so we'll go through it quickly. It's huge, has many interdependencies. The point of this is, if you want to install one software, it might tie in with something else. And so I cannot download the structure for just one program

because I'll have to look at it. OK, it includes that one. I would have to download that one. It includes that one. I would have to download that one. So for now, we download the whole collection. And as I mentioned, 700 megabytes extracted. We use CVS. Maybe it's not a problem.

There's many developers lately within the past two-plus years that use Git with package source. They do their work with Git. But the main tree that's maintained by NetBSD uses CVS. And so if you need to do history or work, you have to have the network connection to the main server, for example.

The implementation, of course, the original FreeBSD implementation. And so we use a lot of shell. And we use make. And so sometimes, make and the shell put together like that can be inefficient. I would say it can be very slow.

But in some cases, it's really quick. Some packaging is redundant. Well, maybe you already use Perl tools or Ruby tools or something to install that software. Does it really make sense to install it again with my packaging system in a different location? That's something to think about.

And we work with different ways to make this clean. But still, it can be redundant. We'll talk about this later. There's too many ways to choose from for doing software updates. Truly, we have over 25 different ways to upgrade your software. And so we have 25 netBSD experts.

They're going to do it 25 different ways. And that works for them. But when you have a new person coming in and they use Yum or apt-get, we cannot tell them 25 different ways to do it. It's a little bit cumbersome. Maybe this isn't a problem. But we support so many different platforms.

And let's say 10 versions of Linux or three versions of Solaris. We cannot provide binary packages for all of these projects. We only provide binary packages for a few things. Then some developers, it's a side project. They might upload theirs. But I already mentioned some developers provide

for Mac OS 10 and things like that. Basic package source usage. This is just an example of a few steps to install some software if you're doing it as a regular user, doing it in your own home. And so you can imagine, I did this on a Linux box. I got the wget.

I downloaded it. I extracted it. This tar was smart enough to understand the XZ format. I go into the package source directory. I go into the bootstrap directory. I ran bootstrap on privileged. Immediately it told me something about my shell. And so normally, as a hacker myself,

I'd figure out, well, why didn't my shell work? But I followed the advice and just said, I'll use Ben Bash. And so I use the shell that it knew worked. It spun. It built some software, like I mentioned before, a make package install. It created a configuration file

that will be used later on by make as it builds install software. And we'll look at that maybe a little bit later. But in my case, I just looked at it. It had some of the defaults. In this case, the defaults meant it was installing from my home or in using my home. And so, yeah, I just jumped into a directory

to build something. And I ran, I didn't set my path yet, but you can see I'm using full path to be make. And I did the install step and then I played it. It's just a simple game. And it had various dependencies that pulled those in. So that's just a very basic example.

And later on, of course, just like with FreeBSD ports or OpenBSD ports, just go into the directory and make install. Oh, one thing as a difference. By default, we don't do a clean or like a clean depends. And so the source over time will fill up. You can set a variable or make variable to clean,

or you can just put it on your command line, install clean, or you can do a make clean later. Oh, just to point out here, BMake is because it's the NetBSD's version. If you're on a NetBSD box, you don't need to do a bootstrap.

It already has a few dependencies already. So simply go into the directory and do a make install. The only thing is there by default, it'll install to user package pkg. Well, we'll talk about the root needs a little bit later. Adjust your path, maybe adjust your man path.

All right, as I mentioned, there's so many different methods. I'm not gonna talk about those today, there's too many. Yeah, and we'll talk about just some of the, sort of the common ones. There's a target that will remove the package and all the packages that depend on it. It keeps a list of those, and then it attempts to rebuild all of those in that list.

So we have a make update target. And then there's a tool that sort of does the same type of thing. A tool to update all packages from sources. So two different ways to do the same thing. Oh, by the way, this package check tool is a third party software.

And so it's another software you can install to manage it. All right, another way, make target replace. So if the package doesn't already exist, like a binary, a tar ball for it, it will tar it up. Generally, this is not a problem anymore. And then it uninstalls it.

Then it builds and installs a new package. Then it fixes metadata that depended on it. So it might update versions of what it depends on to depend on the new version instead. As you can imagine, this could be dangerous because you might replace something that's slightly different, maybe has a different ABI or various different things.

And there's a wrapper around that. We'll look at your system to see what's out of date. So there's a script that some people use that will make replace recursively and all those different things, and which can be dangerous too.

Just a note, I have some systems with packages installed five, six, maybe more years ago, and I just upgrade as needed. And so when I look on there, I still have old software installed with brand new software. And it's sort of a feature, maybe, because it's difficult.

I'm a power user, I guess, and so I can understand how to fix things. The normal usage of somebody on any package system is when they do an upgrade for a new version or they would upgrade quarterly or something. So they upgrade everything in tandem. Keeping things around for many years is possible though

with package source, simply because of some of its portable designs. Binary package usage. And some of this you probably already know. You can do a package add with a URI or you can do a package add directly to the file. And, or you can set the package path variable here.

In this one, you can't see it. The end of it ended with the all directory. And then you can do a package add and it will attempt to figure out the version there, assuming the server there supports those type of things.

We do not have like the minus R switch, but you would do it this way instead. One thing to note about this, I've done this hundreds of times, maybe more over the past 10 years. And so it's downloading the dependencies.

If there's something that breaks in the middle, it can be tough to try to figure out what happened there because it's just a single low level tool. And so, oh, I don't know what happened there. Oh yeah, okay. I'll talk about the next thing. I missed a slide here.

And some other ways for upgrading. And so the minus U switch will update a package in place. And then again, it'll fix the metadata for the other packages that depend on it. And then also if you wanna do a recursively update, minus UU, to do the prerequisite packages also.

And then there's a script you could use to attempt to do the same thing. And when I say binary upgrading, this means that you're not building from source at all, upgrading with binary packages.

Yes, yes, yeah. And so another way to do it. If I teach this lecture again, maybe in a couple, like a year or something, probably might start mentioning the easier tools first.

But in some cases, they still have little nuances. Just like in the FreeBSD world, you wanna use a new tool, they don't even offer the packages on their package servers for some of their versions of FreeBSD. And so little things like that. All right, as I say. So some of the package source-based platforms

like Smart OS or something, they suggest promote document the binary package use only. They don't tell you to download the package source tree. They don't tell you to use a package add tool. They tell you to use other higher level tools, which we'll talk about. And so just quickly, we have a metadata,

like a database containing a list of all the available packages. We call the package summary database. It's based on the same ideas as a Debian available database. And so it allows somebody to use that database to write tools to be able to recursively or upgrade software, install software,

or search what's available. And so there's a few different tools that take advantage of the database. One tool, I just made a hack tool, because I'm one of the people that made this summary database. So I wrote a bunch of shell scripts, maybe set or awk, to use the database

so I can install software. And then two other tools that were created, package in is this one. And then another one is pkg-nih, not invented here. Now, which I don't have slides on that. So package in, as you can see, aimed at being an app or yum-like tool.

And so app get, update, app get, install, simple things. And so it has some of the same functionality. We won't go through all these features. But you can see what's available on your, I'm sorry, what's already installed on your system and what's available.

Do an install. The install target also, or the option there also can do upgrades. You can do an update, downloading what's available. Sort of the app get way. So app get, you would update to get the available database. Then you do your installs. Where the default for yum is a little bit different,

where it'll check for the updates as you use it. And so you can see the bottom one. You can search for packages and so on. And a few other switches also to get more information about what's available.

And I can give you some examples. And so, as I mentioned, some systems I use, I only use package in. And I help maintain different systems for developers. And, oh yeah, I should back up a little bit.

So some of my package source work, I didn't mention all the different platforms I use it on. But I run a build farm for ISC for different bind products. And so we have many different systems where their native package collections do not provide the tools that we need. And so when I need the certain tools,

there was a quote from the earlier thing, earlier presentation today. Make everything standardized. Don't do a one-off. So if I'm gonna learn how to install a third-party software, then heck, I'm going to document my steps so I could redo it again.

And if I'm gonna reuse another software, I'm gonna follow steps and do it again. So might as well document it in a package source specification, that type of way. So anyways, back to package in here. So I see I have 50 software packages installed. The collection available, 11,000 from this one.

And my configuration, it points to the URL where it has the package summary file. And it also has where the binary package tarballs are. And so you can see this example here. Do an update, grabs a new summary database,

updating the database. And then our next example here is searching. You can see here that it says a newer version is available. You can see that with the less than sign. And so that's a candidate for an upgrade. And you can see now I've done that package in update.

I have 200 more packages available from the previous time. And another simple example, installing get host. This one didn't have any dependencies. And so it was very trivial. And there is a switch in a way

you don't have to get prompted. You can turn that prompting off. I don't have a slide for it. But you can do package in, install something with dependencies. And it'll simply give you a list of everything it wants to install. And you've probably seen the same thing on other package systems. And then you can say yes or no. And then it'll let it do its thing.

Also, it'll mention that it wants to upgrade. Let's say it wants to do download fetch install 20 items, but it wants to upgrade five things. It'll tell you that also. Oh, just one more example. I upgraded the software itself.

Package in, install package in. Of course it's already installed because I'm using it. But you can see it did an upgrade. This is a little bit cluttered, as you can imagine. It gives you the removal messages. Then a moment later, it's gonna give me the messages that it installed again.

One thing to note, we won't look at it, but it might have warnings or errors that you detected in the lower level tools. And it'll log those into a file. And you can look at those things. Why does it say updating database? That's one thing to point out. The main metadata for packages are just text files.

Various different text files, meaning different things. And so in this case, package in uses SQLite. And so it puts it into a database that it works with a little bit quicker and a little bit easier. All right, going on to a different topic here.

Work in progress. The WIP, package source WIP, it's at SourceForge. It's very useful for, even for me, if I'm packaging up a bunch of stuff but I cannot get it finished or I just can't get it ported correctly to NetBSD or something that I wanna test it on first, well, I just dump it into their tree.

I can share it with others, and that way they can fix it or they can provide feedback. It's much simpler to point someone to a near completed package versus trying to send some emails, copy and pasting snippets when I can point them to something that's almost ready to use. And so you don't need to be a NetBSD committer.

You just need to, of course, have a SourceForge account then to get permission from the maintainer of that project. So it's very useful for learning. For joint, I don't think so. They do have their own Git repo.

They would have some of their things that haven't been pushed into package source proper, but for work in progress, I don't know. Yeah. And so this is for beginners and for advanced users. Many times I do not use it though. If I make a package, I do it correctly,

I'll just push it directly into the package source tree. May contain broken or unmaintained packages. I don't know how many packages are in it right now, but I assume it's around 700 to 1200, somewhere in that area. Some of them broken are probably my packages. They might be anybody's. If I made a package and never completed it 10 years ago,

it may continue to be broken. All right, another cool feature, cross-compilation. Some parts of it are old, but some parts of it are new. We'll talk about this. So package source is already abstracted for different compilers, and we use a wrapper framework

to try to reorder switches and use compilers in different ways. And you can see all the different compiler systems that we've supported at one time or another, and some of them we still support. It's a big list. And as you can imagine, GCC,

even the command line usage of it is different than maybe an HPUX compiler. And some things are generic and they go across, but some software isn't portable. Let's say they don't use autoconf. And so right here, package source wrappers can help work around problems like that.

And so we're already abstracted for these type of things. But now if you want to do embedded work, you might use distcc or emulators. But here's another way is it's possible to be able to use package source to create packages for a different...

Well, for right now, for netBSD proper. Going back a few years ago, the initial goal was just to get the bootstrap tools to be cross-compile on netBSD. And then the bigger goal is for Xorg X11 suite and its dependencies be cross-compile. But recent work has also added

additional netBSD cross-compile support. So this is a big new feature. And now there's patches in progress or work in progress before doing cross-builds for different platforms. This is gonna be a lot of work. And as you can imagine, using a Mac OS host, that's your quick box,

to generate embedded Linux packages could be very, very nice for a lot of people. It's very significant. For package sources abstracted so much, it will be an easier place to do it than probably any other packaging system. And then the benefit for package source will,

it'll help bring out different issues to even make package source better as we do that. And so that'll be really nice. We have a lot of documentation. We have a guide, a package source guide. It's getting very lengthy.

It's getting longer and longer. It's in HTML. I think it's in PDF. And I look at the text file very frequently. We have a full suite of man pages also, package, add, info, delete, packageinstall.conf, which I'll maybe mention a little bit later. And then there's various wiki pages

where people have put tutorials or how-to, different steps. But this next thing is sort of interesting. It's not complete, but it's a good start. So we have a variety of makefiles or snippets for including into makefiles.

And they might have different things that can be explained. And so we have a makehelp target. We can say the topic and it can give you information about how to use, maybe how to use another target or how to use a make variable. And so it's sort of a built-in help. So that's pretty nice.

All right, so the next thing is another awesome feature of package source, build linking. And we'll get into detail here. But one thing to note is there is a big overhead. And I do some work with Debian packaging at work.

And there's other systems. They're key for making packages. They wanna make a clean package. They don't want it to depend on something accidentally that was already installed on your system. Let's say you had libxml installed. And for some reason, some software you had picked that up. And then you install your package on another system. It won't run because you don't have libxml.

And so the common way to do this is to do it in a trued environment. But the overhead is big because you gotta install all those dependencies. Then when you're done, you need to clean out that entire environment. The overhead could be pretty significant. So package source is a simpler mechanism. Okay, maybe it's not simpler.

It's a lighter mechanism. And so we have various makefile rules to define the dependencies. The dependencies could be very wide. Headers, libraries, there may be package config specifications. They might be libtool archive files.

Just a variety of different things. The package builder might also choose to use some dependencies you already have on your system. Let's say you have OpenSSL. Let's say you have xfree86. You have some type of dependency and you don't want to use a package source equivalent.

Now these are called built-ins. And sometimes it auto detects. And depending on the system, we have some preset defaults of whether or not you may use a built-in. Or we do not provide built-ins for everything. Like we don't wanna provide a built-in for Python 3 or Perl, for example. We will use a package source version of those.

Just simply because some things are too big and trying to manage them from a built-in perspective, that might be very difficult. All right, so it knows what it needs to do a build. So then it creates a symlink tree of all of these specific files. Like I mentioned above, headers or libraries

or libtool archive files. The symlink tree could be extremely huge. If you're installing, let's say, something that uses a QT, for example, in all of its dependencies. You might have layers and layers of dependencies,

a big symlink tree. The next thing is the execute path is overridden to use the wrapper scripts. Also, we set various configure variables or make environment variables. The whole goal is to override different settings used by the compilers or the configuration tools that configure the environment.

And then it will point to directly where we have that symlink tree, the buildlink tree. We'll override those for many different phases of part of the build and the installation. And as I mentioned earlier about abstracting for compilers,

well, we might also do other abstraction here. And as I had mentioned, this has helped to have a very consistent build, prevents the software on the system already installed from being used for creating a new package, even if it's installed from package source, even if it's in user package lib

or user package include where it would look by default. And I had mentioned before that I created a Linux distro. And so that was a little bit tricky because you have user include, which is set by default. But our buildlink tree did help a little bit in that case.

And there's so many different examples, but I just showed a couple of things about what's built in. And so, okay, on this Linux box, it detected that it will use a built-in pthreads. It detected it'll use a built-in open SSL. But for some reason, maybe I didn't have the read line dev package installed

or something. I'm not sure because I didn't look into it. But in this case, it's going to use the package source version. And I already mentioned how it sets different things, but it might override or set different environment variables or configure flags to use the versions that it specifically, specifically depended on.

All right, so you could see an example, a short example of the buildlink simlink tree. Okay, not all of them are simlinks. And so I sort of used the wrong name. In some cases, we dynamically generate PC files. I don't know if we dynamically generate libtool archive files,

but we might. But we put the files in place that would properly point to our versions that we specifically depend on. So sometimes I just cap these files. It'll give a list of the things that were buildlinked.

Buildlinking and x11. And so at one time I had packaged x free 86. Somebody else had packaged x free 86. And then myself and a couple of people, we packaged up xorg.

And then we got rid of that because then we packaged, it was a modular version. So we went through multiple phases of that. And so, but also we support other implementations of x. And I'm not sure how many of these are actively used today.

But we provide another package that provides a simlink tree that'll point to those. That way we could point to the x11 components that they need. Today, most platforms, well, maybe not most, many platforms will default to modular. One thing to note, a netBSD itself will,

by default, will use native. But modular is broken into many, many, many packages. And I just listed a short list here. These are some of the very core ones. I would assume they're all dependencies of libx11.

Let me pause here for a second. Anybody have any questions about the build linking?

Yeah, I'm not sure, but I can imagine. So some of the build link include files also have associated built-in file.

And in some cases, the built-in file might have auto-detected your system wrongly. And so yes, we might have a variable, we can override it. But it really depends on the specific package. One problem is if you have a slightly older version

of free desktop version of the libx11 versus the newer versions, some of them are missing package config files or lib tool archive files. And so it might break in subtle ways. But if you have something specific, you could email me.

So another thing is we do have an options framework. FreeBSD has something similar. FreeBSD's, by default, is interactive. You do an install, you come back an hour later.

Dang, I got to collect these check boxes. And yes, you can install or manually set those ahead of time or have it use the defaults. But least net BSDs is not interactive in this case. You could view them, make show options target. It'll list the general options it has. It'll tell you what's enabled by default.

And also, it'll tell you what's currently enabled, just in case you have configured that somewhere. They should, yes. If they don't, then complain to us. We do have a file that has a description for most of them. And some of the descriptions might be vague,

but they should have a few word descriptions for each one. I should show more examples here. But you could do a site-wide settings with package default options. It could be a whole list, space separated. So just put quotes around it. Or it might do one specific for a certain package, like exam.

The thing that's tricky for new users, if you want to turn off something, put a minus sign in front of it, like dash like attack there, so you could turn off. And these are actual real examples of something that I would use. For example, I'm not using the GUI with Git.

OK, options, just to back up. So our framework right now, as is, does not generate a different package when you tune the package options. And so that means you might have different packages that are different, even though they're named identical, the same. There are some developers who have their own build systems

that name the packages based on the options that you choose. But you can imagine, you might have 50 options. And to have a package name with 50 options following it, and even the tar file name, it can be pretty cluttered and confusing as is. I mean, you're looking at it, oh, man,

that's the longest package name I've ever read. And that won't help you either. It might help you if you only had one or two options. Staged installs, we've had this for at least a couple of years. It's been default for over a year. Basically, what this is is it installs to a temporary staging directory.

And so it installs the entire thing to a staging directory. I think 99% of our software now supports this. And so it is the default. Go in the staging directory so it can check to make sure it's consistent. And then also, one cool thing about this is then you could create a package without installing it

on your system. So it can be a nice feature there, as I mentioned there. Another interesting feature, and so many of our packages define the licenses that are supported. And you can see this list, default acceptable licenses.

And somehow I have two different slides merged together, sorry. But anyways, we have different tools and different things. And so you can define the licenses that you want to support. They can be defined for the package binary tools or defined if you're building from package source. This is really cool because you

could be restrictive or be more open depending on your developer or your production environment rules. And so this can be helpful. So I'm not sure if I'm supposed to end at an exact time, but my lecture ends at the time

allotted. It ends in five minutes. So let me know if I need to end right now or something. This slide right here is, oh, sorry, is the next slide. So just basic packaging steps. I was going to show some live examples. There's many, many different ways to do it. But as I mentioned, when I install software,

I don't want to do it one off. And so I create a step. And there are tools or there's templates that you may use. One tool is called URL to package. And it works for probably over 50% of simple projects. And I've used it hundreds and hundreds of times. And so you basically point it towards a tarball.

It'll download it. It'll open up this tarball and look at it and see if it can get a general gist of how it should be configured and built and installed. And so things that use AutoConf, you can imagine it could do a good basic job. But other things you might have is a simple step.

If you do the make some target, once you've already set something up, it'll download it and create your checksums. Another target that I use often is print p list. And it'll generate your packing list. And so a list of the files and the directories and the directories that should be removed

at deinstallation time and so on. Another target that's useful is a show bar. And so if you want to look at a variable as it's changed, as it goes through the different makefile snippets, you could see what its setting is at that time.

And so I think one of the slides got messed up there, the package lint slide. So I'll just mentioned it very quickly. And so package lint is a tool basically for looking at the sanity of a package. Some developers don't like it at all. I love it. It gives you so many different hints of, oh, you missed this.

Maybe you could do this a better way. It has so many different hints to packaging. It seems very useful to me. One thing to know for packaging, packages should never touch the final configuration file. They should not install directly to your ETC directory. I'd mentioned that before.

They should install to the user share or sorry. But anyways, the examples directory. But there's a few variables you would set. And you would need to make sure that your software uses it from the ETC directory and not from the examples directory. But that's just a little hint or a tip about that.

It's not always true. But many times, you'd use the build link infrastructure for the library dependencies. And as creating new packages, well, of course, we have 11,000, 12,000, maybe 13,000. There's many examples. And there's a very helpful audience. I have to mention, the reason I went to NetBSD

in the first place, and I use other BSDs for other work, is the environment of the package source developers and NetBSD developers in general were so friendly, so helpful. If I asked them a stupid question, they would just prompt me, prompt me, prompt me, and help me be able to solve a problem.

And yes, that can be slow. But it is a very friendly group. And so that was very helpful for me. And so as I mentioned, the helpful group, there are mailing lists. Don't abuse it by being stupid on purpose. But it's very friendly.

And so I'm going to skip the packaging example and just, is somebody else presenting in here right now? I don't think so. This should be the last one, maybe. Oh, OK, OK. And I have one minute, or I can't tell. OK. We've had a vulnerabilities database

for basically 13 years. And so it's a way to, you could have automated. So when you want to build a package, you'll check the database and say, OK, this is vulnerable. And you can set some variables to say, OK, I'll ignore that. Or you could also have an audit tool that runs nightly or however you need to give you a report.

I don't have it listed here, but I, there's thousands and thousands of entries in there. And so it's a pretty, it's maintained pretty well. And it's growing all the time. So it's nice to have a vulnerability database.

I think there was an old package for converting a FreeBSD port to package source. I don't think it's been maintained for many years. It might do a little bit of the job.

I don't know of any others. As I mentioned, there's thousands of vulnerabilities listed. Digital signatures, just to point out, we've had signed package support since 2001. I don't think very many people are using it. But it's a nice feature, and it's a part of our package infrastructure

to be able to have signed packages. I mean, that's very useful. Another thing, very quickly, we've done quarterly stable branches since 2003. I didn't realize it, but that's, I mean, that's a long time. And so we provide another branch,

and we just pull up bug fixes. So if you want to have a stable environment and you don't want to go with a bleeding edge package source, you can stay with a stable branch. So that's another nice feature. And so, yeah, 50 stable branches, that's phenomenal. Just the idea of the package counts. Yes, we don't have as many packages as some.

And how you count packages varies, because we don't break software up into 10 components. But it's a good amount. In fact, it's very good. And you can see some of the counts for different platforms. There is so much more to talk about. And so this slide, I won't talk about them, but you can see I have many.

I am finished. I appreciate you coming and listening and learning more about package source. Feel free to ask me questions about it any time. You could probably ask Al or others. I should personally thank you for the work you've done also. Yeah, there's a lot of people.

Does anybody have any questions? Lots of questions. Okay.