On 26 Aug., 07:51, Keshav Kini <keshav.k...@gmail.com> wrote: > If by rebuilds you mean the forced reinstallation of a package version > that's already installed, I don't see what the problem is.
I meant e.g. installing new spkg foo by * copying it to spkg/standard/ * applying necessary patches for the new foo spkg to the Sage library (and committing them) * running 'env SAGE_UPGRADING=yes make' to (re)build it and also all dependent packages, which includes the Sage library (Note that there are situations where reinstalling / rebuilding the Sage library will fail badly -- eventually quite late -- without having some necessary patches applied, therefore "inconvenient", also preventing automatic testing. In addition, packages in turn depending on the Sage library won't get rebuilt in the first place in that case.) > The procedure I > outlined will do nothing in that case. Nothing will be pulled, so no new > heads will be created. In fact there nothing should get pulled from the unmodified Sage library repo, which contradicts your statement that we'll always end up with "clean" / well-defined repos, ignoring or discarding all changes previously made by a user. If pulling from the "vanilla" repo *did* create a new branch (making it the current head / tip), this would break the above procedure. (In a "real" upgrade, the new Sage library -- and *perhaps* the other repos -- will [currently] almost always have a different tip than the previous one, such that pulling from that new repo should indeed create a new branch and make it the new tip. So the problem IMHO mainly reduces to having to always touch all repos upon new releases, which we planned to *not* longer do IIRC, cf. discussion on sage- release a while ago. Left-around untracked files may be another problem; see below.) Applying the patches to the Sage library in advance, then spkg-disting that (and putting it into spkg/standard/) is also inconvenient just because of the size of the Sage library spkg (>50 MB). I'd have to create and provide such modified Sage library spkgs for each and every new devel release, for IMHO no good reason. (And at least the patchbot will be unable to do this by it/him/herself for a while I guess, even when it/he/she -- hopefully soon -- supports tickets with spkgs, although this is perhaps another story.) > `hg update -c` may fail but I don't see how that's > inconvenient. If it doesn't fail it will simply update to the head, which is > hardly an inconveniece. Or am I missing something? 'hg update -c' apparently ignores new files (not yet added, nor explicitly ignored). It only fails if there are outstanding changes to already tracked files. > I guess by "where" you mean where the file containing the message about what > cleanup needs to be done manually after an upgrade should go. I just meant > that each spkg should append something to, say, $SAGE_ROOT/final_messages , > and then sage-upgrade itself should cat and delete that file at the end of > the whole process. Yep. Although I wouldn't delete such logs after printing them at the end. (However, they *should* end up in install.log anyway.) > Join us in #sagemath on irc.freenode.net I prefer irc.* over chat.* since the former conforms to good old conventions. irc://irc.freenode.net is more explicit, but irc://chat.freenode.net would also be ok. :-) -leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
