Re: [pygtk] ANNOUNCE: PyGTK All-in-one Installer 2.22.6

[John Stowers <john stowers lists gmail com>]

On Wed, 2011-01-19 at 23:02 +0100, Tim Lebedkov wrote:
> Hello Dieter,
> 
> I am really sorry. I have formulated my question so that you have
> completely misunderstood it.
> I hope that at least your explanations could be useful for somebody else.
> 
> Let me explain my concerns in detail. In Npackd (package manager) I
> download packages from different
> locations like http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.26/pygobject-2.26.0-1.win32-py2.7.msi
> To check that the download was OK, I compute the SHA1 checksum of the file.
> For this to work a file placed at a specific URL should never be changed.
> 
> So here is my plea: don't overwrite files, but put new installers
> under a different URL and don't delete old installers.
> Examples:
> http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.26/pygobject-2.26.0-1.win32-py2.7.msi
> http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.26/pygobject-2.26.0-2.win32-py2.7.msi
> http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.26/pygobject-2.26.0-3.win32-py2.7.msi

Old installers are *never* deleted nor silently replaced on the GNOME
site. In fact that was the reason for the creation of the -1 variant; to
fix packaging bugs in windows, no PyGObject code was changed so we didnt
think it necessary to make a new PyGObject release with a version bump.

I'm think Dieter misunderstood your question and offered an incorrect
reply. See below.

> 
> Thank You
> 
> --Tim
> 
> On Wed, Jan 19, 2011 at 10:01 PM, Dieter Verfaillie
> <dieterv optionexplicit be> wrote:
> > On 19/01/2011 20:52, Tim Lebedkov wrote:
> >> am I right that files like
> >> http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.26/pygobject-2.26.0-1.win32-py2.7.msi
> >> are just overwritten with a newer version of the installer?
> >
> > Correct. We do not (yet?) detect the presence of the separate pycairo,
> > pygobject, pygtk, pyrsvg, pygoocanvas and pygtksourceview2 packages.
> > Neither the .exe nor .msi installers.

We don't detect if these have been *installed* on the users system. But
that is orthogonal to your questions (I think). If the all-in-one
installer requires new versions of the component installers then this
will be noted in the release notes and the README.

As mentioned in the release notes, this installer only contains updated
gtk+ runtime, and updated glade installers. PyG* remain unchanged so no
installers were ever silently replaced on the GNOME servers.

So in conclusion, if the all-in-one installer requires newer component
installer for any other PyG* packages, those component installers will
be uploaded to the GNOME servers with a new filename, and the README and
release notes of the all-in-one installer will make this clear.

Hope that clears things up.

John



> This rather unfortunate behavior
> > is documented in the README [1] in the "Migrating from
> > PyGTK+PyGObject+PyCairo packages" section.
> >
> > I guess detecting the separate .exe installers could be done by checking
> > for either or both the "?-wininst.log"/"Remove?.exe" files in Python's
> > installation directory (this idea would need some serious testing though).
> > Detecting the separate .msi installers is a whole other matter: in this case
> > distutils' bdist_msi command does not create the "?-wininst.log" or
> > "Remove?.exe" files. Detection by windows installer product codes might
> > work for known previous releases but we simply can't predict every
> > future release that's going to be created. That and maintaining such a
> > table of product codes would be a maintenance nightmare...
> >
> > Even if the aio installer would grow such a detection method, we cannot
> > provide the same for the inverse situation without seriously hacking
> > about with distutils' bdist_wininst and bdist_msi commands. So it is
> > equally possible to overwrite the aio installers' files by executing
> > on of the separate .exe or .msi installer...
> >
> >> Would it be possible to leave the old installers at their place and
> >> put the new under other names?
> >
> > Not really, the all-in-one installer repackages the content of the separate
> > .msi installers exactly as they are. That's the whole point of the aio
> > installer exercise, really (and was the tedious part to get right).
> >
> > To clarify things, both 2.22.5 and 2.22.6 include the following
> > extension modules (replace the ? with 6 or 7):
> > pycairo-1.8.10.win32-py2.?.msi
> > pygobject-2.26.0-1.win32-py2.?.msi
> > pygtk-2.22.0-1.win32-py2.?.msi
> > pygtksourceview-2.10.1.win32-py2.?.msi
> > pygoocanvas-0.14.2.win32-py2.?.msi
> > pyrsvg-2.32.1.win32-py2.6.msi
> >
> > It is however true that the -1 revision part of the version string
> > for pygtk and pygobject did not show in the "Custom Setup" page when
> > installing. I've fixed that in the build description file [2] and
> > the next version will be more clear about what package versions are
> > included in the UI.
> >
> > Regards,
> > Dieter
> >
> > [1] https://github.com/dieterv/pygtk-installer#readme
> > [2] https://github.com/dieterv/pygtk-installer/blob/master/wix/2.22.7.win32.xml
> >
> _______________________________________________
> pygtk mailing list   pygtk daa com au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/