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

On 01-09-2012 21:40, Matthew Seaman wrote:
> On 01/09/2012 18:43, Tijl Coosemans wrote:
>> In this scenario the ports tree needs to keep support for older releases,
>> but that's a consequence of the fact that there's only one ports tree for
>> all releases. Somewhere in between the ports and the various releases there
>> has to be some form encapsulation, not just for pkg, but for all the tools
>> used by the ports tree. Given how the ports tree currently encapsulates
>> both the old and new pkg tools I don't see how supporting multiple versions
>> of pkgng would be a problem because presumably the difference between pkgng
>> versions is going to be much smaller than the difference between the old
>> and new tools.
> 
> New functionality already in the process of development will entail
> making non-backwards compatible changes to the DB schema.  If we're tied
> to supporting a version of pkgng bundled with a release, that's going to
> make rolling out such changes much harder.
> 
> On the other hand, if pkgng is in ports, then we can release a new
> version and simultaneously publish new package sets (incorporating
> the update to pkgng) from the repositories which will have been built
> using the updated DB schema.

But you cannot update the pkgng repo on the release DVDs.

And also, there's no such thing as simultaneous. After you've updated the
port it takes days even weeks for the package build cluster to rebuild
package sets for all branches and all architectures (think powerpc,
sparc64) and then it takes even more time for the ftp mirrors to pick up
the new set from the master ftp and it takes even more time for a user to
actually update his ports/packages (months to years). During all this
time there can be a difference in version (possibly several versions)
between the pkgng in ports, the pkgng of the official repositories and
the pkgng version that is currently installed on the user's system.

> The ports tree doesn't track the versioning of the base system, and it
> makes perfect sense to me that tools for dealing with the ports should
> follow changes to ports rather than changes to the base.

How about the following:

If you can guarantee that the pkg port can always be built and installed
from ports no matter what version of pkg is currently installed, then the
ports tree only needs to support the version of pkg that is currently in
the tree.

Guaranteeing that the pkg port can always be built probably means it
should set a flag in its Makefile (e.g.BUILDING_PKG) that causes
bsd.port.mk to not use pkg at all until after installation (so it cannot
do conflicts checking for instance). During installation the port also
updates the local pkg registry such that after installation bsd.port.mk
can register the package with the new pkg version.

Special-casing the pkg port this way effectively creates a bootstrap in
the ports tree itself (instead of having a pkg-bootstrap tool in base or
during FreeBSD installation).

Similarly, for package users, pkg should always be able to update itself
from a remote repo no matter what version is currently installed. jhb's
idea of putting pkg in a self extracting script in a fixed location of a
package repo is probably the most flexible. This creates a bootstrap in
every pkg repo.

And then you can put pkg with a pkg repo on FreeBSD release media as
well, such that packages (including pkg) can be installed during and
after installation without needing an internet connection. If there is
an internet connection and the user wants to install packages from a
remote repo, the pkg on the release media can fetch and install pkg from
the repo and then that pkg can be used to install other packages.

I'd be ok with this. The ports tree only has to support one version of
pkgng, there's no separate bootstrap tool, release media are nicely
self-contained and no matter how outdated a user's installed packages
are he can always update using either ports or packages.