Gofer vs Installer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Lukas Renggli
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Miguel Cobá
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
>
Thanks
--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Lukas Renggli
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Stéphane Ducasse
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
12