yes, thank you
On Thu, Jan 20, 2011 at 4:12 AM, John Stowers <[email protected]> wrote: > 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 >> <[email protected]> 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 [email protected] >> http://www.daa.com.au/mailman/listinfo/pygtk >> Read the PyGTK FAQ: http://faq.pygtk.org/ > > > _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
