1 |
> Is it accepted practice to allow for changes in an ebuild without changing |
2 |
> the ebuild version number? |
3 |
|
4 |
It's a bad practice, but it also saves the end user from having to re-emerge |
5 |
packages which have minor changes in them that may or may not affect them. |
6 |
|
7 |
> Background |
8 |
> ---------- |
9 |
> After emerging the latest stable ruby (1.8.2-r1), I found that ruby could |
10 |
> not find some of its modules. The default library paths hardcoded into ruby |
11 |
> were incorrect. To demonstrate: |
12 |
|
13 |
I committed it on Mar 23, and stabilized it on Apr 14th. A minor fix was made |
14 |
by another developer on Apr 19th which should only affect 64 bit users, |
15 |
however, the fix was made with a typo and was caught and fixed on Apr 20th. |
16 |
|
17 |
I guess we took a gamble in not bumping the revision, hoping to not have every |
18 |
Ruby user have to reinstall the package for something that may never have |
19 |
been a problem for them. This decision was helped by the fact that Ruby was |
20 |
rendered useless with this bug, and would force anyone who emerged it during |
21 |
that time would have to seek out some help to sort out the problem. |
22 |
|
23 |
Sorry if it wasn't an obvious solution - a quick look at the ChangeLog and bug |
24 |
reports reference therein quickly provides the resolution. |
25 |
-- |
26 |
gentoo-dev@g.o mailing list |