tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/44062: Inconistencies in PYTHON_VERSIONS_ACCEPTED

(pulling this out of PR 44062 where nobody will see it)

On Mon, Nov 08, 2010 at 01:15:04AM +0000, OBATA Akio wrote:
 >  There are two issues to maintain PYTHON_VERSIONS_ACCEPTED.
 >  It is hard to determine whether:
 >  1) it came from the package itself, or dependency
 >  2) it means only accept those versions, or not accept others

Ideally each package's own PYTHON_VERSIONS_ACCEPTED should reflect
only the properties of that package itself.

If we really need to know the transitive closure of accepted versions
across all dependencies, we can stuff logic into the buildlink files
to compute it automatically.

But I'm not sure there's any point; if you go to build py-foo with
python25 because it only accepts 25, and it depends on py-bar which
only accepts 26, no special logic is needed to make the build
fail. (But, see PR 42894 and related -- I'm assuing problems like that
will eventually get fixed.)

It wouldn't be too hard (I think, anyway) to extend things so that
PYTHON_VERSIONS_ACCEPTED can explicitly blacklist versions; e.g. it
might contain "24 25 -26" to explicitly state that python26 is known
to not work. But I'm not convinced this really solves a real problem
either. When a new python version comes out we can always massedit all

+PYTHON_VERSIONS_ACCEPTED=      24 25 26 # 27?

to explicitly indicate that python27 might or might not work and
hasn't yet been checked.

(remainder of mail kept for tech-pkg's reference)

 >  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)
 >  That's all.
 >  24 should be removed again because py-gtk2 does not accept 24 again and
 >  py-gobject also does not accept 24 now.
 >  26 should be added because it sonata is probably just not
 >  compatible with <24. 
 >  I feel that it is possible to remove incompatible version from
 >  PYTHON_VERSIONS_ACCEPTED 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.
 >  -- 
 >  OBATA Akio /

David A. Holland

Home | Main Index | Thread Index | Old Index