1 |
Yikes - seems my original mail was truncated due to a '.' on a line by itself. |
2 |
|
3 |
This is what I meant to say ... |
4 |
|
5 |
Regards, |
6 |
Imran Sher Rafique |
7 |
|
8 |
Imran Sher Rafique <imran@×××××××.org> wrote on Wed Apr 27, 2005 at 06:09:38AM -0700: |
9 |
> I hope this doesn't come across as too much of a rant. |
10 |
> |
11 |
> Summary |
12 |
> ------- |
13 |
> Is it accepted practice to allow for changes in an ebuild without changing the |
14 |
> ebuild version number? |
15 |
> |
16 |
> |
17 |
> Background |
18 |
> ---------- |
19 |
> After emerging the latest stable ruby (1.8.2-r1), I found that ruby could not |
20 |
> find some of its modules. The default library paths hardcoded into ruby were |
21 |
> incorrect. To demonstrate: |
22 |
> |
23 |
> $ ruby -e '$LOAD_PATH.each {|j| puts "#{j}" }' |
24 |
> /usr/lib/ruby/site_ruby/1.8 |
25 |
> /usr/lib/ruby/site_ruby/1.8/i686-linux |
26 |
> /usr/lib/ruby/site_ruby |
27 |
> ${exec_prefix}/lib/ruby/1.8 |
28 |
> ${exec_prefix}/lib/ruby/1.8/i686-linux |
29 |
> |
30 |
> |
31 |
> Now, after looking through the Changelog (and the bugs referenced therein), I |
32 |
> found that this was an issue which had been addressed and fixed in 1.8.2-r1. So, |
33 |
> why was I experiencing it? |
34 |
> |
35 |
> After some headscratching, I did resync'ed my portage tree to see if there was a |
36 |
> newer ruby ebuild which fixed this issue. No, there wasn't, but I compared the |
37 |
> ebuild used when I emerged |
38 |
> (/var/db/pkg/dev-lang/ruby-1.8.2-r1/ruby-1.8.2-r1.ebuild) with the ebuild in |
39 |
> portage. Guess what - they were different. The buggy sed translation which led |
40 |
> to the above error had been fixed in between my last rsync and now - but the |
41 |
> ebuild version stayed exactly the same. |
42 |
> |
43 |
> |
44 |
> Questions |
45 |
> --------- |
46 |
> Surely, any change to an ebuild should result in its -r* version number being |
47 |
> incremented, at least? Having 2 different files with the same version number |
48 |
> surely leads to ambiguity, which is a big no-no when it comes to release |
49 |
> engineering. |
50 |
> |
51 |
> I can understand not wanting to update the -r* number for every CVS commit. We |
52 |
> can ignore comment changes, etc. But not for bugfixes. |
53 |
> |
54 |
> If the original ebuild was marked stable, and a simple fix was issued (as with |
55 |
> the above example) which corrected a problem with the ebuild rather than |
56 |
> changing the package itself (ie: no additional patches, etc), does this |
57 |
> necessitate the new ebuild (assuming its -r version was incremented) being |
58 |
> marked as unstable? |
59 |
> |
60 |
> If so, then maybe thats the rationale for not automatically incrementing the |
61 |
> version number? In which case, something is broken here. I would argue that |
62 |
> immediately marking the new bugfixed ebuild as stable is the lesser of 2 evils. |
63 |
> |
64 |
> |
65 |
> PS: I don't want to sound as if I am being overly critical of the bug fixers in |
66 |
> question. In the end, I am grateful that you guys fixed the issue :) |
67 |
> |
68 |
> Regards, |
69 |
> Imran Sher Rafique |
70 |
|
71 |
-- |
72 |
gentoo-dev@g.o mailing list |