Gofer vs Installer
Locked
12
12
 
|
> This is something that I can't understand. Is this supposed to be a
> package management system per se, a la Metacello, aptitude, yum?? > Isn't just a installer of MC packages but tries to manage the MC > database of packages in a way that is clean and *atomic*? No, as it says on the first line, it is a tool to perform basic Monticello operations on multiple packages. It is based on scripts that we wrote to handle the 70+ Seaside 3.0 packages, as well as code we wrote for Flair, a system that has similar goals than Metacello, but is now discontinued in favor of Metacello. Maybe Metacello will use Gofer as its loader. > So, there will be a registry of gofer installed operations so that can > be utilized after the install operation (maybe months later)? No. Unless you store them somewhere. The class-side of Gofer has some examples for common set of packages. > Or will just be for trying to install some group of packages and if some > error happens immediatly revert? No. It uses the normal tools available through Monticello, but provides a convenient interface. Furthermore it runs some additional code to keep the image in a clean state. For example it ensures that every working copy has an repository assigned, that repositories pointing to the same physical location are of the same instance, that unused repositories get removed again, that categories are properly ordered, that unload operations do not leave empty categories and protocols, etc. > Can you relate the scenarios showing how gofer is intended to use, > because until now (maybe my narrow perspective) the examples shown can > be done also with ScriptLoader and Installer. Maybe the loading part can be performed by these tools (but then again they mess up with the repositories), but not really the other operations. > Other thing, I tried to convert my image install script but I can't > finish because I install packages from monticello configurations (magma > 1.0r42) and from my local directory repository. Neither of those options > can be handled by gofer (as far as I can see). Of course this can be > corrected, it is just to integrate the correct MC installer classes. Gofer is designed for Monticello only. > That reminds me other thing, Installer can handle monticello > configurations, is the corresponding way of loading the packages using > gofer to list each package in the mcm file in a gofer script? So mcm > will not used or it is just that there have no been time to add those > capability to gofer? Yeah, a Gofer specification is very similar to a Monticello Configuration. In fact when you use specific versions it is basically the same, but then again it messes up with the repositories and categories, something that drives me mad for years already :-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
El lun, 21-09-2009 a las 18:04 +0200, Lukas Renggli escribió:
> > This is something that I can't understand. Is this supposed to be a > > package management system per se, a la Metacello, aptitude, yum?? > > Isn't just a installer of MC packages but tries to manage the MC > > database of packages in a way that is clean and *atomic*? > > No, as it says on the first line, it is a tool to perform basic > Monticello operations on multiple packages. It is based on scripts > that we wrote to handle the 70+ Seaside 3.0 packages, as well as code > we wrote for Flair, a system that has similar goals than Metacello, > but is now discontinued in favor of Metacello. Maybe Metacello will > use Gofer as its loader. ok. > > So, there will be a registry of gofer installed operations so that can > > be utilized after the install operation (maybe months later)? > > No. Unless you store them somewhere. The class-side of Gofer has some > examples for common set of packages. > > > Or will just be for trying to install some group of packages and if some > > error happens immediatly revert? > > No. It uses the normal tools available through Monticello, but > provides a convenient interface. Furthermore it runs some additional > code to keep the image in a clean state. For example it ensures that > every working copy has an repository assigned, that repositories > pointing to the same physical location are of the same instance, that > unused repositories get removed again, that categories are properly > ordered, that unload operations do not leave empty categories and > protocols, etc. > I always tough that monticello have complete control over the packages installed and unloaded from an image. I also assumed that it cleaned its mess after each operation. It is good to know this. But, a question, shouldn't this be part of Monticello. Or monticello fixed so to not leave dirty images behind it. Well that is just a comment. I know that there are alread a dozen monticello versions. :) > > Can you relate the scenarios showing how gofer is intended to use, > > because until now (maybe my narrow perspective) the examples shown can > > be done also with ScriptLoader and Installer. > > Maybe the loading part can be performed by these tools (but then again > they mess up with the repositories), but not really the other > operations. > > > Other thing, I tried to convert my image install script but I can't > > finish because I install packages from monticello configurations (magma > > 1.0r42) and from my local directory repository. Neither of those options > > can be handled by gofer (as far as I can see). Of course this can be > > corrected, it is just to integrate the correct MC installer classes. > > Gofer is designed for Monticello only. ok. > > > That reminds me other thing, Installer can handle monticello > > configurations, is the corresponding way of loading the packages using > > gofer to list each package in the mcm file in a gofer script? So mcm > > will not used or it is just that there have no been time to add those > > capability to gofer? > > Yeah, a Gofer specification is very similar to a Monticello > Configuration. In fact when you use specific versions it is basically > the same, but then again it messes up with the repositories and > categories, something that drives me mad for years already :-) > > Cheers, > Lukas > -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>>> Or will just be for trying to install some group of packages and if some
>>> error happens immediatly revert? >> >> No. It uses the normal tools available through Monticello, but >> provides a convenient interface. Furthermore it runs some additional >> code to keep the image in a clean state. For example it ensures that >> every working copy has an repository assigned, that repositories >> pointing to the same physical location are of the same instance, that >> unused repositories get removed again, that categories are properly >> ordered, that unload operations do not leave empty categories and >> protocols, etc. > > I always tough that monticello have complete control over the packages > installed and unloaded from an image. I also assumed that it cleaned its > mess after each operation. It is good to know this. But, a question, > shouldn't this be part of Monticello. Or monticello fixed so to not > leave dirty images behind it. Well that is just a comment. I know that > there are alread a dozen monticello versions. :) This is not only the fault of Monticello. Some of the problems (duplicated or missing repositories, wrongly ordered categories) only arise when you want to load multiple packages. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
> Can you relate the scenarios showing how gofer is intended to use,
>> because until now (maybe my narrow perspective) the examples shown >> can >> be done also with ScriptLoader and Installer. > > Maybe the loading part can be performed by these tools (but then again > they mess up with the repositories), but not really the other > operations. ScriptLoader is not for public consumption. It is a private class full of crap that we slowly built to sustain our process. I would like slowly move some of the behavior - loadOneAfterTheOther: - loadSilently - mark ; changedPackages either to Gofer or to use gofer to perform certain actions. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |