Hello, Rutherther via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
> Ludovic Courtès <ludovic.cour...@inria.fr> writes: [...] >> Oh right, it’s probably best to change it there. Something like this? > > Yes, that is exactly what I had in mind. OK, pushed as 94c9e53fa4b45e85c1664a9bab6aea0d5c3ac123. I checked in ‘guix system vm gnu/system/install.scm’ that ‘guix describe’ reports the right URL. > Btw I am wondering, is there a policy on (not) updating the released > iso? Release artifacts in general are immutable. But of course, we should make a new release, that’s consensual. :-) >> I’m not sure I follow: even if one uses a mirror of Savannah, downgrade >> prevention works fine. Or are you referring to some other motivation? > > I agree that the prevention works fine even with a mirror. What I wanted > to say is that sometimes it can't work. Like if a repository hosting is > down or you don't have internet connection. That is, if the checkout > (usually the one of root) doesn't contain the commit. Lately, it shows > because savannah is down very often. So one pulls successfully, but then > can't reconfigure, because savannah is down again. This is because root > has a separate checkout. Oh right, got it. Hopefully this particular issue will vanish if we decide to move to Codeberg (GCD 002). > Even if it didn't, if the checkouts are removed, the user can't > reconfigure if repo hosting is down. This just feels like an > unnecessary limitation - why not allow the user to say: yes, this is a > forward update, don't check, ie. --disable-forward-update-check. I was going to say that it’s called ‘--allow-downgrades’, but in fact no, because that still clones/pulls to perform the check and emit a warning (instead of an error). Still, maybe it could catch clone/pull errors? Anyway, that’s for another bug report. :-) Thanks, Ludo’.
