Subject: Re: everything is a dependency and preventing removal
To: None <tech-pkg@NetBSD.ORG>
From: MLH <MLH@goathill.org>
List: tech-pkg
Date: 01/12/2003 04:59:25
On 11 Jan 2003 19:00:00 -0600, Greg A. Woods wrote:
> [ On , January 11, 2003 at 05:46:43 (GMT), MLH wrote: ]
>> Subject: Re: everything is a dependency and preventing removal
>>
>> > Most of the issues I raised have to do with the package database, not
>> > how you initially configure and build a package in isolation.
>> 
>> Yep, we are talking about the same thing.
> 
> No, I don't think we are.
> 
> I'm _not_ talking about how packages are built -- but rather only how
> they are managed on the systems where they are installed.

Precisely. But one component of this is 'can the new package be
built in the current environment?'. If you can't solve that problem,
the rest of it is moot. The solution I proposed also lets you *test*
the next step of the problem - 'can the package be safely updated
in the current environment?'.

> I'm assuming there's a clean way to build binary packages regardless of
> their dependencies and regardless of whether they can be deleted before
> they're re-installed.
> 
> While pkg_install is a special case (it can't be de-installed in order
> to upgrade it because it installs itself), it's indicative of a more
> general problem with critical system packages that cannot first be
> de-installed in order install a different version (i.e. to
> {up,down}grade them).
> 
> Rules have to be devised for INSTALL/DEINSTALL scripts and support has
> to be added so that obsoleted files can be identified and dealt with.

And even if/when you do this, how are you going to be sure that it
actually works?

> Ideally something also should be done such that a very simple procedure
> can be used to undo a failed partial {up,down}grade too -- i.e. the
> package system must not overwrite files, but rather shuffle them around
> some how so that they can be put back if something goes wrong.

For the most part, I think we are primarily choosing different ways
to solve the same problems. Yes, more needs to be done, but many
of the problems you are worried about can at least be easily and
safely tested during an update, which needs to be done regardless
of and before additional steps are designed.

Good Luck!