On Wed, Aug 04, 2010 at 05:05:11PM +0400, Peter Volkov wrote: > В Срд, 04/08/2010 в 09:42 +0000, Jorge Manuel B. S. Vicetto пишет: > > There are already a few bugs that can be attributed to this. > > Ok, let's say that this depends on upstream. And for Gentoo this means > that the decision how to set version for the package depends on > maintainer. Lot's of packages do not have dedicated release tests > upstream (even build tests) and for this packages I don't see difference > between stable branch and release. In such case our version just > indicates that our package is base on tarbal of that version and nothing > more.
The core thing people are ignoring in this discussion is that when you do the following in your python consuming code- python -c 'import sys.version;print sys.version_info' (2, 6, 5, 'final', 0) You know what version of python you're running- not even version as much as what the api is. Code relies on this. When a 2.6.5 is actually a 2.6.6rc* in API but still exporting sys.version == 2.6.5, you screw up consuming code's ability to detect the version and adjust itself accordingly. That right there is a serious problem. Combine that with gentoo's longstanding history of patching things to make it work, but not going insanely beyond that and you've got a pretty strong qa/policy conflict. If you doubt this history, why not look through the python projects previous patch- http://overlays.gentoo.org/proj/python/browser/patches The point people miss in this discussion is that python isn't some standalone pkg- a lot of code consume's it's api's. As such silently pulling in api changes that will land in 2.6.6 starts becoming _extremely_ problematic, and it's contrary to longstanding gentoo maintenance. > > This is unfortunately the main issue here. You may work on a specific > > package on Gentoo, but when that package is essential for the system > > use / stability, it stops being just "your" package. This latest > > example has lead users to a point where their PM stopped working. > > Breaking the PM is not a small "oops" > > That's completely different topic... I'm not talking about stability at > all. Of course, python is special package and should be treated/tested > by maintainers as such! Probably for such core packages ~arch is not > enough and we need different process... But that a different topic. > > Bug I mentioned pretends that we have policy how to set version for > packages that use backported upstream patches. My point is that there is > no such policy and line between _p or -rN is very fuzzy to set such > policy. Thus bug itself is INVALID... This is essentially lawyering; it's not bad until someone creates a rule saying it's bad, even if historical precedent proceeds it. Trying to legislate every possible scenario of common sense/sane maintenance practices leads to insanity. Godel had something to say about this ;) Gentoo generally speaking, is fixed versions of upstream released. We do have integration done, but we don't monkey patch the hell out of their releases- notice also I said 'fixed'. Trying to make 2.6.5 a 2.6.6 isn't exactly "fixing it"- yes there are fixes that should be pulled from the maintenance branch, but there is a very real difference between selective cherry picking and full scale importation as was occuring. ~harring
pgpa0eS2sKdA8.pgp
Description: PGP signature
