pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

Garrett Cooper yanegomi at
Fri Aug 31 15:54:02 UTC 2012

On Fri, Aug 31, 2012 at 8:47 AM, Tijl Coosemans <tijl at> wrote:
> On 31-08-2012 14:22, Baptiste Daroussin wrote:
>> On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote:
>>> On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote:
>>>> On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote:
>>>>> I agree with John on all counts here. Further, the idea of a
>>>>> self-installing package, at least for the pkg stuff itself, addresses
>>>>> the issue that someone else brought up about how to handle installation
>>>>> of pkg by the installer for a new system.
>>>> I like the idea of also providing a self-installing package, and it seems really
>>>> easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5
>>>> minutes which looks pretty good, this could also be a very simple and easy way
>>>> to integrate into bsdinstaller.
>>>> I'll do work in that direction.
>>>> Still it doesn't solve the problem of boostrapping pkgng in a fresh new box,
>>>> because the user may not know where to download the
>>> I do think that is something bsdinstall should be able to handle, and I would
>>> certainly want bsdinstall to include a dialog that says "do you want to install
>>> the package manager?"
>> Of course this is being worked on by dteske@ on his bsdconfig scripts, so yes in
>> anycase the bsdinstaller will end up with a boostrap dialog to install pkgng.
> ...using a mechanism that will be supported for the lifetime of the release.
> My concern is that the problem with the pkg tools was never that they were
> tied to FreeBSD releases. If that were true then you cannot accept the
> bootstrap solution above because it has exactly the same "problems".
> The problem in my opinion was simply that the source code lived in src where
> ports developers didn't have good access to it. And the solution for that is
> to turn pkg development into a third party project and import that into base
> from time to time. There can also be a port for it so people can use more
> recent versions if they want to. That's the situation for several third
> party tools in base.
> Given that the ports tree is currently supporting both the old and new pkg
> tools I don't think it would be a problem for them to support older versions
> of pkgng when the time comes, especially since the database used by pkgng is
> much more flexible and you can execute any sql query on it.
> I also suspect that with pkgng's deployment features the temptation to
> package and deploy base with it are going to be bigger. And if that happens
> you want to ship a version of pkg on the release media and be able to do
> package management from the fixit shell. It would also be nice if the
> installation could fetch the latest security fixes for the release and
> install the latest packages so you don't have to install a browser with
> known vulnerabilities, etc.

    That seems easy to solve with symlinks and/or putting the tarball
in the release directory, so that way bsdconfig downloads the copy
that lives out in the release directory instead of the latest version
in ports.
    Once development stabilizes a bit more, it might be wise to
maintain multiple `release branches` of pkgng so it's possible to
maintain the level of compatibility that FreeBSD users typically

More information about the freebsd-ports mailing list