Yikes - seems my original mail was truncated due to a '.' on a line by itself.
This is what I meant to say ...
Regards,
Imran Sher Rafique
Imran Sher Rafique <[EMAIL PROTECTED]> wrote on Wed Apr 27, 2005 at 06:09:38AM
-0700:
> I hope this doesn't come across as too much of a rant.
>
> Summary
> -------
> Is it accepted practice to allow for changes in an ebuild without changing the
> ebuild version number?
>
>
> Background
> ----------
> After emerging the latest stable ruby (1.8.2-r1), I found that ruby could not
> find some of its modules. The default library paths hardcoded into ruby were
> incorrect. To demonstrate:
>
> $ ruby -e '$LOAD_PATH.each {|j| puts "#{j}" }'
> /usr/lib/ruby/site_ruby/1.8
> /usr/lib/ruby/site_ruby/1.8/i686-linux
> /usr/lib/ruby/site_ruby
> ${exec_prefix}/lib/ruby/1.8
> ${exec_prefix}/lib/ruby/1.8/i686-linux
>
>
> Now, after looking through the Changelog (and the bugs referenced therein), I
> found that this was an issue which had been addressed and fixed in 1.8.2-r1.
> So,
> why was I experiencing it?
>
> After some headscratching, I did resync'ed my portage tree to see if there
> was a
> newer ruby ebuild which fixed this issue. No, there wasn't, but I compared the
> ebuild used when I emerged
> (/var/db/pkg/dev-lang/ruby-1.8.2-r1/ruby-1.8.2-r1.ebuild) with the ebuild in
> portage. Guess what - they were different. The buggy sed translation which led
> to the above error had been fixed in between my last rsync and now - but the
> ebuild version stayed exactly the same.
>
>
> Questions
> ---------
> Surely, any change to an ebuild should result in its -r* version number being
> incremented, at least? Having 2 different files with the same version number
> surely leads to ambiguity, which is a big no-no when it comes to release
> engineering.
>
> I can understand not wanting to update the -r* number for every CVS commit. We
> can ignore comment changes, etc. But not for bugfixes.
>
> If the original ebuild was marked stable, and a simple fix was issued (as with
> the above example) which corrected a problem with the ebuild rather than
> changing the package itself (ie: no additional patches, etc), does this
> necessitate the new ebuild (assuming its -r version was incremented) being
> marked as unstable?
>
> If so, then maybe thats the rationale for not automatically incrementing the
> version number? In which case, something is broken here. I would argue that
> immediately marking the new bugfixed ebuild as stable is the lesser of 2
> evils.
>
>
> PS: I don't want to sound as if I am being overly critical of the bug fixers
> in
> question. In the end, I am grateful that you guys fixed the issue :)
>
> Regards,
> Imran Sher Rafique
--
[email protected] mailing list
