On Thu, Jan 28, 2016 at 05:56:31PM +0000, David Chisnall wrote: > On 28 Jan 2016, at 17:45, NGie Cooper <yaneurabeya_at_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).Received on Thu Jan 28 2016 - 17:17:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC