Date: Fri, 29 Jan 2016 17:03:53 -0500 From: Garrett Wollman <wollman@csail.mit.edu> To: Glen Barber <gjb@FreeBSD.org> Cc: freebsd-pkgbase@FreeBSD.org Subject: TODO/wish list for packaging the FreeBSD base system Message-ID: <22187.57801.906140.971947@khavrinen.csail.mit.edu> In-Reply-To: <20160129173506.GG1727@FreeBSD.org> References: <20160129173506.GG1727@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 29 Jan 2016 17:35:06 +0000, Glen Barber <gjb@FreeBSD.org> said: > - plist prioritization: pkg(8) needs to be aware of package installation > prioritization (ordering), which is one of the items bapt@ is aware > of. In particular, one of the major requirements of this is the > ordering of rtld, libc, and libthr, which must be handled in that > order. There's also the related issue of start/stop ordering for services. Right now (when HANDLE_RC_SCRIPTS is enabled), every service in every package is considered independent, so it can't handle some fairly common cases like: a) Service B depends on data files installed by package A. Upgrading A should stop (or signal in some other way) service B before ripping the data out from under it, and restart B only after B and all of its dependencies have been upgraded. b) Package X declares two services, A and B, which must be started in that order (and stopped in the reverse order). The rcorder constraints in the scripts ensure that this happens correctly at boot, but when upgrading the package, there's no guarantee of the ordering. (Or maybe there is, but it's not the right one as expressed in the rcorder constraints.) [NB: I haven't actually looked at the code -- does HANDLE_RC_SCRIPTS actually parse the rcorder constraints and handle this already?] c) Services A, B, C, and D all depend on library installed by package L. A security update to L requires that all of those services be restarted. Presently, if updates are applied to the package(s) containing those services, they will get restarted automatically, but there is no way to ensure that every service gets restarted short of making a trivial change to downstream packages to force all to be updated. > - Conflicting packages are non-obvious until attempting to install or > upgrade. In a best case scenario, something like the FreeBSD-acct > package may fail to install. In a worst case scenario, this can be > fatal to the system. When FreeBSD-runtime fails to install, pkg(8) > will rollback the changes, which behaviorally leads to removing all > files included in the package - a dead system. While ZFS is not something we can require, it would be good to have hooks in the system that would allow for, e.g., automatically creating a ZFS snapshot before/after updating certain packages. > TODO List / Wish List: FreeBSD-update as it stands goes to significant lengths to limit the amount of data that must be transferred to install a patch. In particular, it uses bsdiff(1)/bspatch(1) to generate binary patches to avoid transferring complete files. It would be good if pkg(8) had a concept of a "patch package" that can be reversibly applied to an existing package (as stored in the /var/cache/pkg) to transform it into an updated package, which can then be installed. Obviously, reproducible builds would be required to accomplish this. I don't know if pkg(8) can do this already, but having a "quick upgrade" mode that does not update files known (by comparing hashes in the package database) to be unchanged may be worthwhile -- but obviously would need to be optional. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22187.57801.906140.971947>