| 1 |
On a similar topic to the -fPIC question, I've realized today that |
| 2 |
|
| 3 |
if use alpha; then |
| 4 |
epatch ${FILESDIR}/${P}-alpha.patch || die "epatch failed" |
| 5 |
fi |
| 6 |
|
| 7 |
is really the wrong thing (and I'm not talking about the die part, which |
| 8 |
I know is controversial). I'm talking about the conditional application |
| 9 |
of the patch. |
| 10 |
|
| 11 |
I think this should really be: |
| 12 |
|
| 13 |
# Patch for 64-bit but apply everywhere |
| 14 |
epatch ${FILESDIR}/${P}-alpha.patch || die "epatch failed" |
| 15 |
|
| 16 |
The reason is twofold: |
| 17 |
|
| 18 |
1. Devs presently break packages by bumping the version without |
| 19 |
reworking the patch. But they don't KNOW they broke the package |
| 20 |
because they're working on a different architecture. |
| 21 |
Consequently, the arch teams get a bug report that just ends up |
| 22 |
being busy-work. |
| 23 |
|
| 24 |
2. We shouldn't be applying patches that are only "safe" for one |
| 25 |
architecture. If possible (and I know this is a little more |
| 26 |
work), we should be writing patches that correct the problem |
| 27 |
without hurting other arches. This practice would give us an |
| 28 |
easier time pushing patches upstream. |
| 29 |
|
| 30 |
So what happens if a dev bumps the version on a package, and the patch |
| 31 |
no longer applies? Here's what I think: |
| 32 |
|
| 33 |
1. The dev should attempt to rework the patch, or determine if it |
| 34 |
can be removed. |
| 35 |
|
| 36 |
2. If it's too involved, then the dev should remove the arch or |
| 37 |
~arch keyword from the ebuild, comment out the patch, and send |
| 38 |
email to the appropriate arch team. That keeps users from |
| 39 |
attempting to update their systems only to have emerge fail in |
| 40 |
the middle for their arch. Better to have the devs handle the |
| 41 |
problem than push it on to the users. |
| 42 |
|
| 43 |
Does this make sense to everybody? I'm pushing for this approach |
| 44 |
because our current situation truly has a scalability problem. We have |
| 45 |
more devs available for working on packages than we have for working on |
| 46 |
alternative architectures (where alternative means non-x86). It's |
| 47 |
really important that devs responsible for packages attempt to keep |
| 48 |
their ebuilds cross-platform friendly and not rely on the arch teams to |
| 49 |
come along and clean up afterward. |
| 50 |
|
| 51 |
I'm not suggesting that anybody has been careless, but I am suggesting a |
| 52 |
change in perspective on Gentoo's multi-arch support... |
| 53 |
|
| 54 |
Thoughts? |
| 55 |
|
| 56 |
Aron |
| 57 |
|
| 58 |
-- |
| 59 |
Aron Griffis |
| 60 |
Gentoo Linux Developer (alpha / ia64 / ruby / vim) |
| 61 |
Key fingerprint = E3B6 8734 C2D6 B5E5 AE76 FB3A 26B1 C5E3 2010 4EB0 |
Archives