| Summary: | dev-lang/python: $PV does not reflect actual sources | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Brian Harring (RETIRED) <ferringb> |
| Component: | New packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | amd64, betelgeuse, fauli, nelchael, pva, qa, seemantk, tomka |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
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).
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. 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. (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? (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. 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. 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. 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. 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... (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. 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. (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. (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. (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. (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. Arfie- what's the status? Last I checked the 2.6.6 patches, looked sane. What's the state of 2.6.5? (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. |
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?