On Thu, Jan 28, 2016 at 06:23:22PM +0000, Glen Barber wrote: > On Thu, Jan 28, 2016 at 09:12:53PM +0300, Slawa Olhovchenkov wrote: > > I see two hudge problem for support upgrades from older RELEASE > > versions (supported too): key (used for repo signing) change and need > > to access ports packages to install (installed outdated release can't > > find pkg packet for install). > > > > Can you more detailed describe current propolsal of new packaging > > system? pkg is part of base installed packages? Or after installing > > base packages pkg installed from `ports`? For disc1.iso case. > > > > How handled boot/device.hints and var/db/etcupdate? > > > > How handled boot block updates? > > These are all valid questions, but let's take a step back for a bit, and > not put the carriage in front of the horse. > > The initial email in this thread was intended to provide an update on > the status. Some things, such as file merging, is already in place in > a few of the packages. Not all, yet. Initial email in this thread will about problems at upgrades, from my point of view and my expirence. I am currently try to upgrade systems by untar base.txz and see some inconsistence of packaging (boot/device.hints, var/db, var/log/sendmail.st, var/db/etcupdate) and etc. Sorry if this a different problem. For me -- all of this -- question of global design. Need administrativa about some questions: - how divide - how fresh install - how upgrade (on runnig system, from install media). - what packed to disk always - what got from internet - what about custom releases and src.conf I am don't know how currenly resolved this questions. Bundled with upgraded files fresh pkg (building for LAST-2 release) and preserving for 10+ years this files can resolve many issuse of upgrading outdated systems (by hop-to-hop or hop to hop+2). I am don't know about complexity this solution. > Unexpected things are going to happen. That is the only thing that is > a guarantee right now. In other words, implementation (from what is now > in the project branch) may change. And yes, there needs to be a way to > upgrade from older releases. I am ask for you check. This very complex task and need good planing. > But let's not get too far ahead of ourselves. > > Glen >Received on Thu Jan 28 2016 - 17:57:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC