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 <diet...@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 > _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
