From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j3RDeYkt020401 for ; Wed, 27 Apr 2005 13:40:35 GMT Received: from mail21.sea5.speakeasy.net ([69.17.117.23]) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DQmmO-0000Rl-Cx for gentoo-dev@lists.gentoo.org; Wed, 27 Apr 2005 13:40:40 +0000 Received: (qmail 11670 invoked from network); 27 Apr 2005 13:40:40 -0000 Received: from dsl027-183-224.sfo1.dsl.speakeasy.net (HELO rafique.org) ([216.27.183.224]) (envelope-sender ) by mail21.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Apr 2005 13:40:40 -0000 Date: Wed, 27 Apr 2005 06:56:50 -0700 From: Imran Sher Rafique To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: why do different ebuilds have the same version number? Message-ID: <20050427135650.GH20252@ulric.rafique.org> Mail-Followup-To: gentoo-dev@gentoo.org References: <20050427130938.GG20252@ulric.rafique.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050427130938.GG20252@ulric.rafique.org> User-Agent: Mutt/1.4i X-Uptime: 06:55:25 up 228 days, 9:27, 0 users, load average: 0.13, 0.03, 0.01 X-Archives-Salt: 5fb32e10-b6ea-4663-bd48-bfaaed99b381 X-Archives-Hash: f203ce5a35c22e1f64bf6a3a46dc9292 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 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 -- gentoo-dev@gentoo.org mailing list