Dieter Verfaillie wrote: >>>>> Hmm, isn't this package part of freedesktop rather than >>>>> gtk+ ? And amazingly, this 1 file and empty dirs is GPL... >>>>> So it can't be included in a LGPL (+compatible) package ? >>> >>> When constructing the windows all-in-one installer I've asked myself >>> the same question and came to the conclusion that: >>> - the installer logic is GPL'ed (my choice); >>> - the software packages that are installed carry their own license, >>> which the user still needs to honor. >> >> I wanted my package to be LGPL, and the packaging scripts are KISS / PD. > > Sure, and that's OK. Just trying to say that you don't necessarily need > to worry about the licenses of the goods that are being transported affecting > the license of the vessel (the package/installer) or the tools creating the > vessel, as there's no runtime linking going on, etc > > At least, that's how I'm interpreting these licenses. IANAL, beware, etc :)
Yeah, I've heard it before so I think that's the common interpretation: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation Partly I'm wondering how a set of directories could need a license, but. The actual package tools and the package format are proprietary anyway. Using Apple's venerable PackageMaker, and the pkg/bom/xar file format. The bundle "packages" are regular bsdtar tarballs, though. >> (as it's the fourth or fifth time I'm installing PyGTK as a dependency!) > > Yeah, we're in the same situation on windows, where it is (strongly) > recommended that each "product" (gimp, inkscape, pidgin, wireshark, etc) > comes with it's own "platform environment" (GTK+ and friends). From a user > perspective that can be confusing at times, but the technical reasoning > behind that recommendation is sound. That part is the same on Mac OS X... I would say that it "makes sense" from a user perspective (in that it's easier to handle, manually), but that the technical reasoning behind it is very simplistic and limited. What I meant is that I've done one package for MacPorts, one for Fink, one for GTK-OSX using Jhbuild, one for Homebrew, and now this custom one. Main reason being that all of the other four variants were source-based. >> I'm using tgz files and different scripts, but otherwise it's the same. >> The Windows libraries are also relocatable, while I use /opt/gtk rpath. >> >> Other difference was that I didn't include developer files (headers/libs), >> but that was more for size reasons since I'm including 3 architectures... > > These are all fine by me and I'll not discuss/dispute (? lack of proper > English > vocabulary on my part, sorry) the choices you make as I don't even own a mac > machine myself. So that's up to the actual users of the package :) The versions and selection was directly modeled after the Windows bundle. (http://www.gtk.org/download-windows.html and download-windows-64bit.html) >>> I encountered Glade installing icons into the "hicolor-icon-theme", >>> other software does the same, so I've included "hicolor-icon-theme" >>> in the installer. As noted above, hicolor is nothing more than an empty >>> directory structure so I've added the Tango icon theme as well (a >>> personal preference, but nobody has complained yet). >> >> That would be my preference as well. Including SVG, because I like it. >> Hmm, what else do you have there... PyGtkSourceView2, PyGooCanvas ? > > PyCairo, PyGObject, PyGTK, PyGtkSourceView2, PyGooCanvas and PyRsvg > (the last one comes from gnome-python-desktop), Glade3, "language tools" > (intltool, gettext, etc) and dependencies. A complete list can be seen here: > https://github.com/dieterv/pygtk-installer/blob/release-2.22.6/wix/2.22.6.win32.xml Yeah, meant "that I didn't include" there. The developer tools like pkg-config and gettext are available, just not in the deployment pkg. > I've had requests to add PyGTKSpell/PyEnchant by our gramps friends and > time permitting I'll add them to the 2.24 aio installer (I hope). > >> Glade is already available from http://glade.gnome.org/ for Mac OS X. >> (including another bundle of GTK inside). Only included libglade-2.0. > > There was no (sane) Glade3 binary package available for windows at the time, > so the work is tracked here: > https://bugzilla.gnome.org/show_bug.cgi?id=634978 :) > Also, the Glade3 version bundled in the PyGTK aio installers comes with > "Python widgets support", so we can finally add a catalog of > widgets created with PyGTK to Glade3 running on windows :) > That brings the number of different Glade3 version up to 3 on windows: > 1 supporting Python 2.6, 1 supporting Python 2.7 and one without Python > support. I don't think I will bother with Python 2.7, already supporting Python 2.5 (for 10.5) and Python 2.6 (for 10.6) so that's enough. > That brings me to an idea: do you think it would be worth it to share > common parts (manifest generation, compression routines, etc) of these > build scripts in a shared repository somewhere? I'm not sure where the manifest generation and compression routines come in, other than that I was using the built-in gzip for "simplicity". Recompressing the package with XZ results in a much smaller package, but then you'd need people to install that (or bundle xzdec, ~ 50 KB) 26M PyGTK.pkg 14M PyGTK.pkg.xz And that's bound to fail. Though I might switch .tgz to .txz later. Guess that would be similar to switching .zip to .7z for Windows ? > I'm asking because my next project will most likely be an adaptation on > Tor Lillqvist's windows binary build scripts so they can be run out of the box > on any windows system (having the necessary tools) as the current scripts are > limited to Tor's development environment... Eventually (one day) I'll rewrite these scripts into a generic tool. Right after I make my own "distro". But they should be runnable now. --anders _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
