Sébastien Gendre <[email protected]> writes: > Thank you for your reply. > > > Rutherther <[email protected]> writes: > >> This is not possible with guix system easily. Guix channel commonly keeps >> only one version of a package in current source code, so you cannot just >> specify older version to stay on, when you guix pull, and reconfigure, >> everything will be at the versions that are declared in the channels. >> If you aren't ready to update, use guix instance with same channels as >> with previous reconfigure. > > Ok, at least I can just don't run `guix pull' before. What I want to > avoid is : > > * When adding a new service with its package, having all the other > services that update their packages including to a new major version > > * When updating 1 package to have a security patch, having my e-mail > service who also update and crash, resulting of choosing between > security or no e-mail > > > But if, in my `operating-system', I have a package defined like this: > > (specification->package "[email protected]") > > Does a `guix pull' and a `guix system reconfigure' only update prosody > if a package corresponding to the 0.12 is available ? And otherwise do > nothing ?
Yes, exactly, specification->package just looks through all currently available packages and matches one with the given name + optionally a version. > > Like, if I have the 0.12.1 installed and a `guix pull' give me access to > a definition of the version 0.12.2, the update is done while > reconfigure. But if the definiton of the package prosody is at version > 0.13.0 the update is not done ? No, guix system build/reconfigure doesn't know what packages are installed, it doesn't check that. While it would be possible to do something like that with custom commands, it's not in guix and I don't know if someone implemented that. Note that this goes only for home and system build/reconfigure. It isn't true for guix install where this is already possible, if you guix install `package@version`, if this version disappears from newly pulled guix, it will remain at that version until you unpin it explicitely. guix package (guix install is wrapper around that) checks the original profile's manifest and works with that. On the other hand note that this isn't playing nicely with propagated inputs. You can expect problems with pinned packages if you used it for example for python packages or for glib packages. For many issues you will get a build error, so you will notice right away. But for some issues you might end up with runtime errors only. (those can usually be resolved though, by unsetting some environment variables, I think the most problematic I've seen is the GIO_EXTRA_MODULES) > > >> There are some exceptions, like gcc, where even older major versions are >> kept, and there you can refer to older versions, either through symbols >> or through specifications. >> >> If you wanted to pin some packages, you can use inferiors, but they >> aren't easy for achieving the goal you want of keeping packages at given >> version until you want to update. > > I have to see what are the inferiors.
