Gentoo Archives: gentoo-python

From: Dirkjan Ochtman <djc@g.o>
To: Mike Gilbert <floppym@g.o>
Cc: gentoo-python@l.g.o
Subject: Re: [gentoo-python] Testing dev-lang/python version bumps
Date: Fri, 27 Apr 2012 16:35:29
Message-Id: CAKmKYaAzqhH+Y=--RGT7zrHAxM2+1Q6jOtPP0P4b3mhtZiHCnA@mail.gmail.com
In Reply to: Re: [gentoo-python] Testing dev-lang/python version bumps by Mike Gilbert
1 On Fri, Apr 27, 2012 at 17:13, Mike Gilbert <floppym@g.o> wrote:
2 > To be honest, I did not look into each patch in great detail. I really
3 > just tested the resulting builds to make sure they did not break
4 > anything obvious.
5
6 I can imagine, I just think it's probably good if we do look at
7 patches in detail.
8
9 >> 3. Added 61_all_process_data.patch, for which the goal seems somewhat unclear.
10 > This is some logic for python-wrapper that was in the 2.7.2 patchset as
11 > well. If you want to drop it, I'm sure that will require some
12 > re-engineering of python-wrapper.
13
14 Right. Do you know what this fixes, and how/why it will be
15 re-engineered? As long as we don't know these things, I'd prefer to
16 leave the patch out rather than include it.
17
18 >> You also removed the mention of the upstream bug from
19 >> 04_all_libdir.patch, probably just by mistake?
20 >
21 > I don't see any mention of a bug in the 2.7.2, 2.7.3 or 2.7.3-0 version
22 > of the patch, so I'm not sure what you are referring to here.
23
24 Are you sure? The 04* patch I just unpacked from my 2.7.3 patch set
25 does have a bug in it (maybe it wasn't in 2.7.2, though).
26
27 >> Including
28 >> 26_all_gdbm-1.9.patch in 3.1.5 is probably a good idea. For 3.1.5's
29 >> 09_all_sys.platform_linux2.patch, I'd prefer if we just reuse
30 >> ${FILESDIR}/linux2.patch, unless that doesn't apply for some reason.
31 >
32 > I don't really see a difference either way. I guess it is more visible
33 > in the ebuild.
34
35 I like the fact that it's a single patch for all the versions, and
36 that we don't have to manage it separately in the patch sets.
37
38 >> Now, we can certainly discuss adding these patches on this list, but I
39 >> think we should try to maintain some balance on the upside of having
40 >> extra fixes in our ebuilds and the amount of maintenance we're willing
41 >> to do on carrying those patches forward (e.g. the distutils patch is a
42 >> pretty big pain, and it seems like more of a feature than a bug).
43 >
44 > Well, that does seem to be Arfrever's baby, so as long as he keeps
45 > rebase it, we should be ok.
46
47 Yeah, I'd really prefer to have us not depend on Arfrever for our
48 dev-lang/python updates. IMO we should drop this from 3.3 pending
49 upstream movement.
50
51 > That makes sense. I will keep it in mind.
52 >
53 > Would you like me to cut a new set of tarballs without 08, 22, and 23?
54
55 That would be perfect. I'd also still like to drop 61 unless we have a
56 clear picture of what/why it helps (and can document that in the
57 patch).
58
59 Cheers,
60
61 Dirkjan

Replies