1 |
On Fri, Oct 20, 2006 at 05:26:00PM -0700, Brian Harring wrote: |
2 |
> On Fri, Oct 20, 2006 at 11:05:22PM +0000, malverian@g.o wrote: |
3 |
> > Hello all, |
4 |
> > |
5 |
> > In designing an enterprise infrastructure around Gentoo at my place of |
6 |
> > employment, I have discovered a feature that would improve Gentoo's |
7 |
> > usefulness greatly in this field. |
8 |
> > |
9 |
> > I'm writing to ask for your opinion on a change to sys-apps/portage that |
10 |
> > would allow users to maintain local revisions of ebuilds, such as |
11 |
> > "net-www/apache-2.0.58-r2-local1". This would require a modification to |
12 |
> > the ebuild version specifications and a patch to two portage source |
13 |
> > files which you can review here: |
14 |
> |
15 |
> Use -rX.Y instead; existing portage will choke on it the same as it'll |
16 |
> choke on -local, upshot of -rX.Y is that it's less chars, bit more |
17 |
> clear in the intention of trying to sneak an additional version |
18 |
> component betwee -rN and -rN+1 |
19 |
> |
20 |
|
21 |
I suppose I see the benefit of this and as long as it accomplishes the |
22 |
same thing I'm looking for here, I would not be opposed. However, I |
23 |
think having a local version of "apache-2.0.58" resulting in |
24 |
"apache-2.0.58-r0.1" is kinda silly. |
25 |
|
26 |
Regardless of which method we choose, it needs to be strictly enforced |
27 |
that packages in the gentoo-x86 tree NOT use these revision numbers or |
28 |
it will ruin the whole point of them. |
29 |
|
30 |
> |
31 |
> > http://dev.gentoo.org/~malverian/portage_local_version.patch |
32 |
> > |
33 |
> > (Please don't complain about the code quality, I cleaned up areas where |
34 |
> > it was desparately needed such as the string.atof() areas, but for the |
35 |
> > sake of code coherence, I tried to use the same methodology used elsewhere |
36 |
> > in the code as much as possible, such as unqualified except statements :P) |
37 |
> |
38 |
> Bah. If you know that catch-all except's are bad, that means you |
39 |
> can't use that excuse for having it in your new code :P |
40 |
> |
41 |
|
42 |
I get a little slack since the patch is simply a proof of concept ;) |
43 |
|
44 |
> |
45 |
> > 2) You are using binary packages and need to simulate a version bump to |
46 |
> > force re-installation of a binary package with modified USE flags. |
47 |
> > |
48 |
> > 3) You are using binary packages and need to simulate a version bump to |
49 |
> > force re-installation of binary packages that were rebuilt during |
50 |
> > revdep-rebuild |
51 |
> |
52 |
> Failing here is that it's not a 'simulated' verbump, it *is* a verbump |
53 |
> for any deps that are locked via =; =dev-util/diffball-0.7.1 will not |
54 |
> pick up =dev-util/diffball-0.7.1-local1 since =dev-util/diffball-0.7.1 |
55 |
> is implicitly =dev-util/diffball-0.7.1-local0 . |
56 |
> |
57 |
> Folks can live with that issue, but should be clear that its there |
58 |
> (same for revbumps of course, just picking at the wording). |
59 |
> |
60 |
|
61 |
This is a good point, but I think the types of people that would be |
62 |
using this feature will not have a problem making changes like this. |
63 |
Optionally I guess we could drop the -local# in dep calculation? It's |
64 |
two separate pieces of code already as you can see from the patch. |
65 |
|
66 |
> |
67 |
> > In all of the above cases, one could simply bump the package up one |
68 |
> > revision by creating an ebuild in an overlay for apache-2.0.58-r3. |
69 |
> > However, using this solution will result in apache not being upgraded |
70 |
> > when apache-2.0.58-r3 is actually committed to the portage tree unless |
71 |
> > you perpetuate this bad habit ad nauseum. |
72 |
> |
73 |
> This particular issue (force usage of an ebuild from PORTDIR if the |
74 |
> installed exact version is from an overlay) can be addressed without |
75 |
> changing version rules, although admittedly it's a single revbump, no |
76 |
> way to do multiple bumps (again, wording is all). |
77 |
> |
78 |
> |
79 |
|
80 |
I don't see any benefit to this method over the one I proposed. |
81 |
|
82 |
> > - The new (completely backward compatible) version priority order would be: |
83 |
> > |
84 |
> > apache-2.0.58 |
85 |
> > apache-2.0.58-r1 |
86 |
> > apache-2.0.58-r2 |
87 |
> > apache-2.0.58-r2-local1 |
88 |
> > apache-2.0.58-r2-local2 |
89 |
> > apache-2.0.58-r3 |
90 |
> > apache-2.0.59 |
91 |
> |
92 |
> portage_version.ver_regexp specifically anchors -r\d+ to the end of |
93 |
> the string, as such this is *not* backwards compatible, 2.1 |
94 |
> would choke if it saw these versions in the vdb or in an |
95 |
> overlay... |
96 |
> |
97 |
|
98 |
That's correct, the regexp in current portage does require -r# to be |
99 |
anchored to the end. However, since the gentoo-x86 tree will not have |
100 |
packages with -local# someone would have to specifically try to use this |
101 |
new feature in an old version of portage in order to have issues. |
102 |
|
103 |
This argument here can also be applied to the -r#.# solution you |
104 |
mentioned, so I think the decision between -r#.# and -local# is really |
105 |
just a matter of aesthetics. I'm on the fence as to which is best. |
106 |
|
107 |
Would you be in support of a change that allowed for either -r#.# or |
108 |
-local# local revisions? |
109 |
|
110 |
> ~harring |
111 |
|
112 |
|
113 |
-- |
114 |
gentoo-dev@g.o mailing list |