[systemd-devel] 'Offline System Updates' examination

[Lennart Poettering]

On Thu, 21.06.12 18:23, Alexander E. Patrakov (patrakov at gmail.com) wrote:

> 
> 2012/6/21 Lennart Poettering <lennart at poettering.net>:
> > If source based distros want to implement this I'd probably recommend
> > them to compile everything in the system, and only do the final step,
> > the installation as part of the system-update step.
> 
> The problem is that your recommendation (if I understand it correctly)
> does not work, at all.
> 
> Suppose that there are two packages to update, icu and libreoffice.
> Libreoffice depends on icu, and for the reason of simplicity of the
> argument let's pretend that there are no other packages in the system
> that use icu. If your recommendation is to be followed literally, the
> package manager needs to compile icu (thus creating either a binary
> package or a tree where it can run "make install" later), compile
> libreoffice the same way, then install both results later. However,
> this would lead to installation of libreoffice compiled against the
> old icu, which may or may not work. Libreoffice should really be
> compiled with the new icu already installed, and this is directly
> against the "install all updates in one big batch" approach.
> 
> So, could you please clarify the recommendation in the aspect of
> dealing with such dependencies? The "install to btrfs snapshot"
> approach would handle this correctly by installing each package as
> soon as it gets compiled.

But this looks like a limiation of the build system, no? The build
system should be capable of building against a non-installed
version. The binary distro auto builders can do that...

I think this really should be fixed in the build system, not in the
system-update.target logic.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.