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 
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

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to