Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 330667 - dev-lang/python: $PV does not reflect actual sources
Summary: dev-lang/python: $PV does not reflect actual sources
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Python Gentoo Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-01 00:29 UTC by Brian Harring (RETIRED)
Modified: 2010-12-31 16:26 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Harring (RETIRED) gentoo-dev 2010-08-01 00:29:26 UTC
Brought this up in person in #-council, but apparently it's being ignored.  Thus the bug.

For building python-3.1.2, we have the raw upstream released tarball, and gentoo-patches; gentoo-patches has a lovely 00-* patch within it that is a 300kloc delta applied to 3.1.

As to how this patch is generated, per arfrever's statement of how this is generated follows:

14:45 < Arfrever> ferringb: I'm unpacking tarball, running `svn export ${branch}`, removing unneeded files/directories and creating patch.
14:46 < Arfrever> ferringb: The script ignores: .bzrignore .hgignore configure Doc Include/patchlevel.h Mac PC PCbuild RISCOS
14:47 < Arfrever> ferringb: Changes in configure.in aren't ignored, so eautoreconf applies appropriate changes to configure.

In effect, grab 3.1 release branch, export it, than generate the delta against released 3.1.2.

This literally means gentoo's 3.1.2 is _not_ 3.1.2, it's a pre of 3.1.3.  This is also contrary to how gentoo does patching of released versions- by and large, we only pull in fixes, we do not heavily mangle the crap out of versions like redhat and others do.

Finally... the way this patch is generated means we don't actually track what goes into it- we're purely trusting upstreams intermediate commits.  Good example is upstream bug 7384 (http://bugs.python.org/issue7384); released 3.1.2 works fine, with that patch pulled in it induces locale breakages via ldd invocations, and general unawareness of encodings.

Basically, we're not running 3.1.2.  The process of generating that patch hides the fact that it's a 3.1.3 pre (at best), is effectively untracked, and is contrary to gentoo policy for patching.

Question is, now that the mess is made, yet again how do we stop it from becoming worse, and how do we get it sane again?
Comment 1 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-08-01 16:09:15 UTC
Maintainers have right to backport changes from upstream.
I want to provide more bug fixes for Python users.
The patch is relatively big, because reindentation of C files was backported. Later fixes in C files wouldn't apply without backporting it.
It's easier to maintain 1 big patch than 100 small patches.
In future ebuilds, I might use improved ${PV} (e.g. 3.1.2_p2010XXXX).
Comment 2 Dirkjan Ochtman gentoo-dev 2010-08-01 20:12:46 UTC
I ran into a faulty backport from the 2.6 maintenance branch as well due to it being in Gentoo's 2.6.5-r1 or -r2 or something. I suggested that it might be better to just stay with the release tarballs then.
Comment 3 Dirkjan Ochtman gentoo-dev 2010-08-01 20:14:02 UTC
Arfrever, I don't think you should just close this without having an actual discussion. While I agree that providing backports for bugfixes can be nice, I think that the predictability of using release tarballs with minimal patches might be better in this case. Re-opening for further discussion.
Comment 4 Petteri Räty (RETIRED) gentoo-dev 2010-08-01 20:38:24 UTC
(In reply to comment #3)
> Arfrever, I don't think you should just close this without having an actual
> discussion. While I agree that providing backports for bugfixes can be nice, I
> think that the predictability of using release tarballs with minimal patches
> might be better in this case. Re-opening for further discussion.
> 

Bugzilla is not a place of discussion. If there's something to debate it should be taken to the mailing lists.

(In reply to comment #1)
> Maintainers have right to backport changes from upstream.

Yes but they are also required to version their ebuilds properly. I think our arch teams want to base our core packages close official releases (with important bug fix / security fix patches applied when needed) instead of some random snapshots. x86/amd64: What's your thought on the situation as we have 3.1.2-3 stable?
Comment 5 Brian Harring (RETIRED) gentoo-dev 2010-08-01 21:11:15 UTC
(In reply to comment #1)
> Maintainers have right to backport changes from upstream.

Maintainers are required to abide by the distro standards.  One of 'em, is that we don't patch the ever loving shit out of a package mangling it well past the actual released version.

Whether you get it or not, while you work on these packages, they are *not* yours to do whatever you want with.  Standards apply.
Comment 6 Seemant Kulleen 2010-08-01 21:19:35 UTC
I would agree with the dissenters on this issue.  In gentoo when one emerges a version with a release version, one expects to get something as close to that release version as possible.

For backporting fixes, I think you might look into releasing both the official version as 3.1.2 and also your fixes as 3.1.2_p<date_stamp>.

That way, users who expect the factory release get that, and those who want to be closer to cutting edge can get that.

Please consider doing this, as python is a hugely important package in the world of gentoo.
Comment 7 SpanKY gentoo-dev 2010-08-02 01:09:28 UTC
seemant from nowhere !

at any rate, yes, you cannot use PV==3.1.2 unless it is based on the actual 3.1.2 release.  if you're doing random branch snapshots, you need to label it appropriately.  using something like 3.1.2_p<timestamp> or _p<svnrev> is trivial to do.
Comment 8 Christian Faulhammer (RETIRED) gentoo-dev 2010-08-02 06:42:26 UTC
This sounds like total brain-dead to me.  Selected bug fixes are ok, but not unconditionally unloading such a huge pile on users without researching the effect.
Comment 9 Markos Chandras (RETIRED) gentoo-dev 2010-08-02 15:32:03 UTC
I am not really happy to have such a package stable for amd64 but I don't see a smooth way to deal with this. Too late I am affraid...
Comment 10 Petteri Räty (RETIRED) gentoo-dev 2010-08-02 18:11:13 UTC
(In reply to comment #9)
> I am not really happy to have such a package stable for amd64 but I don't see a
> smooth way to deal with this. Too late I am affraid...
> 

Adding a new -rN based on actual release and with only reviewed patches come to mind.
Comment 11 SpanKY gentoo-dev 2010-08-03 01:38:26 UTC
if the code base is past 3.1.2, then moving to -r# doesnt make much sense.  using a 3.1.2_p# will avoid any downgrades and label it appropriately.
Comment 12 Petteri Räty (RETIRED) gentoo-dev 2010-08-03 05:28:04 UTC
(In reply to comment #11)
> if the code base is past 3.1.2, then moving to -r# doesnt make much sense. 
> using a 3.1.2_p# will avoid any downgrades and label it appropriately.
> 

For new bumps by the python team yes. The question is if we want to make our stable users downgrade in the upstream sense using a new -rN . Of course the issue will fix itself with 3.1.3 or 3.2 going stable assuming the python team doesn't keep deceiving the rest of us.
Comment 13 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-08-04 20:02:58 UTC
(In reply to comment #9)

Stabilization rules are the same. Each package can be stabilized after 30 days of testing and no regressions. Even snapshots of sys-libs/glibc were stabilized.
Comment 14 Mark Loeser (RETIRED) gentoo-dev 2010-08-04 20:37:38 UTC
(In reply to comment #13)
> (In reply to comment #9)
> 
> Stabilization rules are the same. Each package can be stabilized after 30 days
> of testing and no regressions. Even snapshots of sys-libs/glibc were
> stabilized.
> 

Yes, but they were labeled appropriately so people knew it was a snapshot.  That's the whole point of this bug.
Comment 15 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-08-07 17:56:12 UTC
(In reply to comment #14)
> Yes, but they were labeled appropriately so people knew it was a snapshot. 
> That's the whole point of this bug.

I fixed versioning in dev-lang/python-2.6.5_p20100801 and dev-lang/python-3.1.2_p20100801.
Comment 16 Brian Harring (RETIRED) gentoo-dev 2010-12-31 16:18:10 UTC
Arfie- what's the status?

Last I checked the 2.6.6 patches, looked sane.  What's the state of 2.6.5?
Comment 17 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-12-31 16:26:21 UTC
(In reply to comment #16)
> Arfie- what's the status?
> 
> Last I checked the 2.6.6 patches, looked sane.  What's the state of 2.6.5?

I'm not any Arfie, but I think that this bug is also fixed in 2.6.6 and 3.1.3. 2.6.5* and 3.1.2* will be deleted from the tree when it will be possible.