Re: New ncurses packages...
> > However, I will say
> > that the biggest problem area is the allowing of packages to remain in
> > an unpacked but unconfigured state (i.e. the old package has been
> > removed but the postinst for the new one has not yet been run) for an
> > indefinite period of time. Perhaps this feature should be removed for
> > essential packages.
>
> I don't think this is the problem. Remember that if we *ever* let
> the system get into a broken state we might find that something goes
> wrong at a bad moment and then we're stuck. So, we need to make sure
> that the system is never so broken that it can't recover, and so we
> need to make sure that essential packages which are merely unpacked
> and not configured are sufficiently un-broken to support the rest of
> the installation procedure.
I think this is a problem. Here is one scenario which hopefully
illustrates my point. Libgdbm1 is (as I understand it) essential
since it is needed by perl which is needed by many postinst scripts.
If a user were to upgrade libgdbm1 along with other packages, there
would be a period of time after the postrm for the old libgdbm1 was
run and before the postinst for the new libgdbm was run where no
working libgdbm1 could be found by perl. The only reason this doesn't
break right now is because the postrm for libgdbm1 leaves an
installed, working version behind intentionally. Unfortunately, this
also leads to the possibility of leaving installed versions behind
unintentionally.
> > Another problem area is the ordering of calls to
> > the postrm and postinst scripts. I'm at a loss for a good example
> > right now, but some problems could be more easily solved if the postrm
> > for the old package were called after the postinst for the new
> > package.
>
> That will break lots of things which use install-info, update-rc.d,
> &c, because they often add things in the postinst and remove them in
> the postrm without thinking about their arguments.
This is why I haven't and am not pushing for such a change. BTW,
isn't it better to remove these types of things in the prerm? That's
where I've been doing them.
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: