Just now, Sam Tobin-Hochstadt wrote: > On Dec 8, 2012 10:14 PM, "Eli Barzilay" <e...@barzilay.org> wrote: > > > > I think that this is exactly what Matthew was talking about. One > > tricky bit here is to know which packages were installed for which > > level. If *you* installed some packages, then the next time you > > *run* (not install) an updated racket version you'd be asked if > > you want to do the migration. But if some package was installed > > as part of the racket tree (not user specific) then the same > > question would apply when a new version gets installed. > > Why would this wait for the first run for any packages?
As usual, think about a lab with a central sysadmin-made racket installation. It's impossible to crawl over all users and change stuff in their home directory when the sysadmin upgrades the installation. Now carry this over to OSX and Windows, and it's the same thing. (And even Windows is moving toward a more strict separation between the administrator and plain users.) The thing that makes it somewhat easier there is that the interaction tends to be a single user that plays both roles. So either the user installed some packages "for everyone" and the upgrade will update those at installation time, or the user installed things for himself, and the upgrade will happen when the new version runs -- usually just after the new installation. > One other thing that I think is important in a migration path is > keeping any modification made to the source of the packages that are > already installed. Yeah -- and IIUC, the difference between the two installations is where the packages get installed is where the compiled files are, so the sources are the same. At least I *hope* that that's how it is, otherwise it's back to the whole planet "cache" things, which IMO was a major mistake. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________ Racket Developers list: http://lists.racket-lang.org/dev