On Thu, 21.06.12 18:23, Alexander E. Patrakov (patra...@gmail.com) wrote: > > 2012/6/21 Lennart Poettering <lenn...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
