# Packaging the FreeBSD base system with pkg(8)



## protocelt (Jan 27, 2016)

For anyone that doesn't keep up with the mailing lists and is interested or curious about the status of the work being done to package the base system with pkg(8) , Glen Barber has posted some information about it on the new freebsd-pkgbase mailing list: https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-January/000000.html


----------



## ShelLuser (Jun 28, 2016)

I figured this might be the best place for this question, I'm already going over the mailinglist but it seems more focused on testing than discussing (I'm still reading, but will have to postpone the rest for later).

To be honest I'm a little worried because I consider the separation between the base system and the package management system a huge pro. Even if a package maintainer messes up with something trivial such as a dependency setting then this can never have any impact on the base system, unlike with some other popular Unix-like operating system.

So I'm quite curious if anyone knows if this system will become optional or mandatory? I can definitely see how this might provide a much easier (and more consistent) replacement for freebsd-update, but what about those who don't use freebsd-update in the first place?

I don't like to be negative, but this is a setup I'd never want to apply on my systems.


----------



## wblock@ (Jun 28, 2016)

I'm looking forward to it.  It will be a better way to update systems than freebsd-update(8).  Of course it won't replace building from source, it's just an option.  But it also might make it easy to build very small, tailored base systems, including only the binaries needed to run.


----------



## Murph (Jun 28, 2016)

It should be a step in the right direction in the long term.  The commercial Unix world (Solaris, HP-UX, AIX, OS X, and others) has had the base system under packaging for quite some time, and it works quite nicely.  Being able to add/remove/list/verify/patch/etc base components and packages under a common set of tools is really quite nice.  With suitable granularity, it can allow things like replacing base services/daemons (e.g. BIND, Sendmail, NTP, etc) with newer/alternate packages much more cleanly than the 10.x status quo; including just as easily reverting to the base packages.  Theoretically, no more messy situations of duplicate functionality being simultaneously installed in base and /usr/local; with corresponding confusion about which version of command line tools you are getting in each shell, etc.

There's no fundamental reason why a problem with a port should disrupt the base packages, if the implementation is done correctly, unless the user does something like `--force --live-dangerously --yes-really --just-do-it`.  Now, I'm not saying that pkg necessarily has that level of safety today (I don't know for sure just where it's at), only that there's no fundamental reason why it can't be made as safe as that in terms of preventing base and ports easily having a bad collision.


----------



## kpa (Jun 28, 2016)

Dependency errors as you most often see are really from our ports system which has some really mundane cruft from the old days still left and it's an ongoing battle to get those fixed. The base system on the other hand would be packaged by hand tailored manifests (which are automatically generated for ports) with much tighter control, you have to remember that the ports system is not used when building world/kernel and none of its rules apply and none of its infrastructure nor its features/bugs are not available.


----------



## ANOKNUSA (Jun 29, 2016)

I already responded to ShelLuser in this thread, but since this is a more dedicated thread, I'll restate it here: base-system and third-party packages are intended to be handled separately, and the package management system is being updated accordingly.

I only recently subscribed to the mailing list, so I can't say how many of the existing issues have been worked out; but it doesn't seem like the developers are in a rush to finalize the change until it works properly. I'm also not sure if a new command set is being added to pkg so that base-system and package upgrades can be run separately, which would be my only real concern. Forcing users to either upgrade their packages whenever a new base system security patch is released or not update at all would be a huge oversight, so I really doubt I'm the first person to think about that.


----------

