On Thu, Jan 28, 2016 at 05:56:31PM +0000, David Chisnall wrote:
> On 28 Jan 2016, at 17:45, NGie Cooper <yaneurab...@gmail.com> wrote:
> > Also, consider that you're going to be allowing upgrades from older RELEASE
> > versions of the OS which might be using a fixed copy of pkgng -- how are
> > you going to support that?
> I believe that the plan is to promote the pkg tool somewhat closer to the
> base system. Upgrades will do the same sort of thing that they do currently
> for ports:
> 1. First check if the version of pkg is the latest
> 2. If not, upgrade it
upgrade to latest version build for older release?
> 3. Do the real upgrade
> The package for package is simply a tarball. It may be advantageous to
> separate the pkg and pkg-static binaries into different packages, so that pkg
> can always install pkg-static and pkg-static can always update pkg.
> There is no guarantee that the pkg tool from X.Y can install any packages
> from X+n.Y.m other than the pkg-static binary, which can then upgrade the
> rest of the system.
> The provision of pkg-static prevents us from being in the situation
> that I encountered trying to upgrade a Debian system (and ending up
> with a mess requiring a full reinstall) where apt needed a newer
> glibc and the glibc package needed a newer apt to install it. We
> will always provide a pkg-static for every supported branch that can
> be installed by any earlier version of pkg (because it’s just
> extracting a single-file archive - and in the absolute worst case
> you can do this by hand) and can install newer packages.
Even pkg-static build for 10.x can be fail to run on previos release.
Builded svn-static on 9.x fail to run on 6.x, as result I build
svn-static on 6.x (and run on 6.x-10.x).
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"