pkgsrc-Bugs archive

[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" <>
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 <> 
 >  >  For audio/sonata, PYTHON_VERSIONS_ACCEPTED was changed as followings in 
 > Makefile:
 >  >  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 
 > because
 >  >  current it is impossible to determine whether current mark of 
 > incompatibility
 >  >  came from the package itself or dependency.
 >  >  PYTHON_VERSIONS_INCOMPATIBLE may be used for it, but not used anywhere.
 >  As 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
 >  ( The same for PHP and Apache versions. 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 is not included before
 any of py-*/
 OBATA Akio /

Home | Main Index | Thread Index | Old Index