py-gtk unified

[Ryan Schmidt]

On Dec 7, 2012, at 18:08, Aljaž Srebrnič wrote:

> On 08/dic/2012, at 00:32, Ryan Schmidt wrote:
> 
>> On Dec 7, 2012, at 09:23, Aljaž Srebrnič wrote:
>> 
>>> I propose to unify everything under the name py2[5-7]-gtk2 since we have the gtk2 port. We could mark the -gtk ports replaced_by its -gtk2 counterparts. What do you think?
>> 
>> Bear in mind that we also have a gtk3 port already. Does pygtk support gtk3, or will it? If so, we should think about how we plan to handle that. (Separate py-gtk3 port? Subports? Variants?)
> 
> Fortunately, py-gtk won't support gtk3, there is another module for gtk3 named pyGObject [1].
> 
> [1] - http://stackoverflow.com/questions/5920049/learning-gui-programming-with-gtk2-or-gtk3

Ok, that's good to know.

I assume the reason why the py25 thru py27 ports are called gtk not gtk2 is that the module name is pygtk not pygtk2. There was a recent push to make sure the entire module name appears in the port name; under that theory, the port should be called py-pygtk.

Whatever you change the name to, all ports depending on pygtk will have to have their dependencies updated and their revisions increased.


> I'm attaching the actial diff, if anyone want to take a look before I commit.
> <py-gtk2.patch>

You can leave out "python.default_version 27"; that is the default, when "24" is not in python.versions.

The dependencies should go inside the "if {${name} != ${subport}}" block, since the stub port does not actually depend on those other ports. The "use_configure yes" command also needs to go in that block, since its presence globally will cause the stub port to fail. The build and destroot changes could also go in that block since the stub port does not actually build or destroot anything, though having them set globally does not seem to cause problems, and there is precedent for keeping them global, since we habitually set master_sites and checksums outside that block, even though the stub port does not fetch any files.

The active_variants 1.1 portgroup should be used, with which you no longer need to put the require_active_variants in a pre-configure block manually.