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

[Tim Lebedkov <tim lebedkov googlemail com>]

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

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. 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
>