[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/44062: Inconsistencies in PYTHON_VERSIONS_ACCEPTED
The following reply was made to PR pkg/44062; it has been noted by GNATS.
From: "OBATA Akio" <obache%netbsd.org@localhost>
Subject: Re: pkg/44062: Inconsistencies in PYTHON_VERSIONS_ACCEPTED
Date: Mon, 08 Nov 2010 20:37:43 +0900
On Mon, 08 Nov 2010 19:55:03 +0900, Aleksey Cheusov <cheusov%tut.by@localhost>
> > For audio/sonata, PYTHON_VERSIONS_ACCEPTED was changed as followings in
> > r1.1: 24 (maximum version, probably not compatible with 23,22,...)
> > r1.2: +25 (python25 added, assumed that it is compatible with 24)
> > r1.7: -24 (py-gtk2 does not accept 24)
> > r1.8: +24 (py-gtk2 accept 24 again)
> For manual package testing wip/pkg_summary-utils may be used
> (>=0.47 is strongly recomended).
That's not what I mean.
It may be detected automatically, but need to digging history to find
how to fix.
> > I feel that it is possible to remove incompatible version from
> > recursively and automatically, but hard to add new acceptable version
> > current it is impossible to determine whether current mark of
> > came from the package itself or dependency.
> > PYTHON_VERSIONS_INCOMPATIBLE may be used for it, but not used anywhere.
> As bl3.mk is used for handling python-based dependencies, deriving
> incompatible python versions from dependencies whould not be a big
> problem I think. That is, a list of incompatible pythons should be set
> once both for package itself (Makefile) and for dependent packages
> (buildlink3.mk). The same for PHP and Apache versions.
buildlink3.mk should not be used for the purpose.
If it used for resolve PYTHON_VERSIONS_ACCEPTED,
it will be hard to do recursive revision bump from shlib version bump.
And it will not work as expected if pyversion.mk is not included before
any of py-*/buildlink3.mk.
OBATA Akio / obache%NetBSD.org@localhost
Main Index |
Thread Index |