On Saturday, August 27, 2011 2:22:11 PM UTC+8, leif wrote: > > On 26 Aug., 07:51, Keshav Kini <kesha...@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.) > > I guess I didn't give too much thought to other situations in which sage is "upgraded", other than when you just type `sage -upgrade [url]` on the command line. Shouldn't rebuilds ideally be semantically separated from "upgrades"? Not that I have any idea what that entails in Sage...
> > > 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. > Er, yeah, I meant you would get a "clean" new version, assuming you were actually upgrading :) I doubt anyone would expect "-upgrade" to revert their current version to a (prior) clean state. I also meant that you would get a clean working directory, not a clean repo, though again only in the case you were actually upgrading. > > 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.) > > Any relation to #10231 <http://trac.sagemath.org/sage_trac/ticket/10231>? > 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. > Yup, which I figured was a desirable behavior, per various people's suggestions to not balk at unknown files lying around. > > > > 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.) > > Sure, we could instead attach the file to install.log after printing it. The main point would be to make sure we don't print messages from previous upgrades during the current one. > > > 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. :-) > > Me too, that's why I said irc.freenode.net :P BTW that wasn't really part of my message, just a manual signature I append to my messages when I remember, as an advertisement! > > -leif > -Keshav ---- Join us in #sagemath on irc.freenode.net <irc://irc.freenode.net/sagemath> ! -- 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
