DragonFly BSD
DragonFly users List (threaded) for 2006-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: pkg_chk replacement?

From: Marcin Jessa <lists@xxxxxxxxx>
Date: Tue, 24 Jan 2006 18:41:30 +0000

On Tue, 24 Jan 2006 19:12:36 +0100
joerg@xxxxxxxxxxxxxxxxx wrote:

> On Tue, Jan 24, 2006 at 04:27:10PM +0100, Marcin Jessa wrote:
> > Seems like all the outdated packages are deinstalled by pkg_chk before
> > they get upgraded to a more recent version.
> And what should it do different? 

What about updating package by package without 
deinstalling all of them to begin with just as portupgrade on FreeBSD?
The outdated dependiences of an upgrade candidate get upgraded first etc.

>Don't do live builds on a server, the down time is always unpredictable.

The behaviour of pkg_chk deinstalling all the update candidats at once
makes russian roulette way more predictible.
An example of how sucky this is would be updating your desktop.
First it deinstalls all the packages it wants to upgrade. If you're unlucky to
have your wm and (X)term deinstalled and the term crashes during
update you will not only lose your X session but also the entire list of
packages you had on the system. I was lucky when this happened building
package list first so I could restore the missing files.
If I did not predict something like that could happen I would be totally screwed
and could not work for quite some time having unsuable desktop.

> Using inplace updates still breaks
> the software for a certain window if successful, and can result in
> silent breakage being detected much later. That's why I rejected the
> addition of replace-all recently on tech-pkg.

If you mean behaviour similar to the one portupgrade has you should reconsider.
The behaviour described above is absolutelly more desirable than the current one.
> If you want to have consistent updates and a predicatable downtime,
> build the software in a jail / chroot as binary packages and use those
> to update. That's also the easiest solution if you want to actually test
> them before using them in production...

An unacceptable thing if you want a userfriendly system.
Way too difficult for an avarage user. 99% of them would give up.
This will automatically leave users with binaries only and for that they already
have Debian...


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]