Re: Why is python a dependency of gtk2?

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Fri, Nov 27, 2009 at 1:52 PM, Jens Rehsack 
<rehsack%googlemail.com@localhost> wrote:
> Currently all packages depending on python will not work.
> I tested successfully building and running editors/vim-gtk2 without
> python (on Solaris, we currently have some minor issues building on
> AIX) - so there is no reason to deny use editors/vim-gtk2 because of
> other package might fail mysteriously.

I'm not against making things work, but I'm strongly against using
package options for the wrong purpose.

> Python is neither a documented dependency for gtk2 on it's homepage,
> nor in the packaged INSTALL file.

It's not documented just as the dependencies on make or sh are not
documented -- Python is installed ~everywhere by default, so the
developers can't "imagine" that using Python can be a problem.

>> There really is nothing to "fix" here.
>
> It is something to fix here: There is a not upstream required dependency
> which prevents using on platform where the dependency does not work.
> This breaks the entire package.

No.  What is broken is Python, not gtk.  So what should be fixed is
Python.  But see below!

> How sounds following for you: python will be optional, but choosen by
> default (everywhere). If disabled, a warning is displayed (or a
> PKG_FAIL_REASON is set, unless GTK_WITHOUT_PYTHON is set), so that's
> ensured that the user knows exactly what (s)he is doing and is aware
> of potential follow-up errors.

Again, making this an *option* is a very bad solution.  I should have
elaborated more this morning on what could be better, but I didn't
have time.  A more appropriate alternative is what Joerg suggested:
making it a separate package.  This way you can keep correct track of
dependencies in all platforms, at the same time, and not break
anything unexpectedly.

The eventual best solution for this would be to add support to pkgsrc
to generate different binary packages form the same source and do what
Linux distributions do: a libgtk package and a libgtk-dev package, out
of the same build, and each with different dependency sets.  But,
unfortunately, we are far from this :-(  Thus, creating a manual,
separate package is the closest alternative.

-- 
Julio Merino