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

[Tim Lebedkov <tim lebedkov googlemail com>]

yes, thank you

On Thu, Jan 20, 2011 at 4:12 AM, John Stowers
<john stowers lists gmail com> 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
>> <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/
>
>
>