[gentoo-dev] why do different ebuilds have the same version number?

[gentoo-dev] why do different ebuilds have the same version number?

[Imran Sher Rafique]

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
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] why do different ebuilds have the same version number?

[Caleb Tennis]

> Is it accepted practice to allow for changes in an ebuild without changing
> the ebuild version number?

It's a bad practice, but it also saves the end user from having to re-emerge 
packages which have minor changes in them that may or may not affect them.

> 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:

I committed it on Mar 23, and stabilized it on Apr 14th.  A minor fix was made 
by another developer on Apr 19th which should only affect 64 bit users, 
however, the fix was made with a typo and was caught and fixed on Apr 20th.

I guess we took a gamble in not bumping the revision, hoping to not have every 
Ruby user have to reinstall the package for something that may never have 
been a problem for them.  This decision was helped by the fact that Ruby was 
rendered useless with this bug, and would force anyone who emerged it during 
that time would have to seek out some help to sort out the problem.

Sorry if it wasn't an obvious solution - a quick look at the ChangeLog and bug 
reports reference therein quickly provides the resolution.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] why do different ebuilds have the same version number?

[Mike Frysinger]

On Wednesday 27 April 2005 09:09 am, Imran Sher Rafique wrote:
> Is it accepted practice to allow for changes in an ebuild without changing
> the ebuild version number?

yes & no ... read the developer policy doc for full details :p
http://www.gentoo.org/proj/en/devrel/handbook/
-mike
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: why do different ebuilds have the same version number?

[Imran Sher Rafique]

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 <imran@rafique.org> 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

Re: [gentoo-dev] why do different ebuilds have the same version number?

[marduk]

On Wed, 27 Apr 2005 06:09:38 -0700, "Imran Sher Rafique"
<imran@rafique.org> said:
> 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?

Unfortunately yes ;-).  This also has been a problem for
packages.gentoo.org code, because I basically have to make a series of
assumptions as to when an ebuild is considered "new" or "updated". 
Originally I thought I could just just look at the timestamps on the
ebuilds, but that turned out to be a very bad determiniation of when an
ebuild has changed.  Then I thought revision numbers, but that's
innacurate too.  Basically now it comes down to looking at the current
ebuild in portage and comparing it to the last time I looked at it. 
It's much more expensive, because you have to look at *every* ebuild,
not just "ebuilds changed since x date/time" or "ebuilds newer than
version y".  Oh no, now I sound like I'm ranting ;-)

-m
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] why do different ebuilds have the same version number?

[Brian Harring]

On Wed, Apr 27, 2005 at 10:53:04AM -0700, marduk wrote:
> 
> On Wed, 27 Apr 2005 06:09:38 -0700, "Imran Sher Rafique"
> <imran@rafique.org> said:
> > 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?
> 
> Unfortunately yes ;-).  This also has been a problem for
> packages.gentoo.org code, because I basically have to make a series of
> assumptions as to when an ebuild is considered "new" or "updated". 
> Originally I thought I could just just look at the timestamps on the
> ebuilds,
Relying on mtime of an ebuild and it's eclass should suffice.  
Any changes that don't affect any of those timestamps portage won't 
handle properly from the cache perspective...
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] why do different ebuilds have the same version number?

[Francesco Riosa]

marduk wrote:

>On Wed, 27 Apr 2005 06:09:38 -0700, "Imran Sher Rafique"
><imran@rafique.org> said:
>  
>
>>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?
>>    
>>
>
>Unfortunately yes ;-).  This also has been a problem for
>packages.gentoo.org code, because I basically have to make a series of
>assumptions as to when an ebuild is considered "new" or "updated". 
>Originally I thought I could just just look at the timestamps on the
>ebuilds, but that turned out to be a very bad determiniation of when an
>ebuild has changed.  Then I thought revision numbers, but that's
>innacurate too.  Basically now it comes down to looking at the current
>ebuild in portage and comparing it to the last time I looked at it. 
>It's much more expensive, because you have to look at *every* ebuild,
>not just "ebuilds changed since x date/time" or "ebuilds newer than
>version y".  Oh no, now I sound like I'm ranting ;-)
>
>-m
>  
>
Why you could not use ctime/mtime ? Isn't possible to make a check like
you do now but only on a filtered by "mtime" list of ebuild ?
A command like this
# find . -name "*.ebuild" -and -mtime "-7" -or -ctime "-7"
give you a list of ebuilds created/modified in the last seven days.
Isn't this enough to be sure you are looking at all ebuilds modified in
the last 24 hours ? At least to cut down the number of ebuilds to check.
i.e. I'm assuming it's only a problem of precision


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] why do different ebuilds have the same version number?

[Brian Harring]

On Wed, Apr 27, 2005 at 09:17:46PM +0200, Francesco Riosa wrote:
> marduk wrote:
> 
> >On Wed, 27 Apr 2005 06:09:38 -0700, "Imran Sher Rafique"
> ><imran@rafique.org> said:
> >  
> >
> >>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?
> >>    
> >>
> >
> >Unfortunately yes ;-).  This also has been a problem for
> >packages.gentoo.org code, because I basically have to make a series of
> >assumptions as to when an ebuild is considered "new" or "updated". 
> >Originally I thought I could just just look at the timestamps on the
> >ebuilds, but that turned out to be a very bad determiniation of when an
> >ebuild has changed.  Then I thought revision numbers, but that's
> >innacurate too.  Basically now it comes down to looking at the current
> >ebuild in portage and comparing it to the last time I looked at it. 
> >It's much more expensive, because you have to look at *every* ebuild,
> >not just "ebuilds changed since x date/time" or "ebuilds newer than
> >version y".  Oh no, now I sound like I'm ranting ;-)
> >
> >-m
> >  
> >
> Why you could not use ctime/mtime ? Isn't possible to make a check like
> you do now but only on a filtered by "mtime" list of ebuild ?
> A command like this
> # find . -name "*.ebuild" -and -mtime "-7" -or -ctime "-7"
Actually... nope. :)
You're forgetting about eclass changes, which can adjust metadata 
(deps) of an ebuild w/out the ebuild ever being modified...
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] why do different ebuilds have the same version number?

[Francesco Riosa]

Brian Harring wrote:

>>>[snip]
>>>      
>>>
>>Why you could not use ctime/mtime ? Isn't possible to make a check like
>>you do now but only on a filtered by "mtime" list of ebuild ?
>>A command like this
>># find . -name "*.ebuild" -and -mtime "-7" -or -ctime "-7"
>>    
>>
>Actually... nope. :)
>You're forgetting about eclass changes, which can adjust metadata 
>(deps) of an ebuild w/out the ebuild ever being modified...
>~brian
>  
>
right was forgotting that :P , what about something like this ?

HAS_MODIFIED_ECLASS=$( find /usr/portage/eclass/ -name "*.eclass" -and
-ctime "-1" -mtime "-1" )
if [[ -z  $HAS_MODIFIED_ECLASS ]] ; then
  echo "Good, using faster method"   
  find /usr/portage -name "*.ebuild" \
  -and -mtime "-1" \
  -or -ctime "-1" \
  -exec something_here.sh
else
  find /usr/portage -name "*.ebuild" \
  -exec something_here.sh
fi

will save you often, eclasses are not so frequently updated ;-)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] why do different ebuilds have the same version number?

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

On Wed, Apr 27, 2005 at 10:02:27PM +0200, Francesco Riosa wrote:
> Brian Harring wrote:
> 
> >>>[snip]
> >>>      
> >>>
> >>Why you could not use ctime/mtime ? Isn't possible to make a check like
> >>you do now but only on a filtered by "mtime" list of ebuild ?
> >>A command like this
> >># find . -name "*.ebuild" -and -mtime "-7" -or -ctime "-7"
> >>    
> >>
> >Actually... nope. :)
> >You're forgetting about eclass changes, which can adjust metadata 
> >(deps) of an ebuild w/out the ebuild ever being modified...
> >~brian
> >  
> >
> right was forgotting that :P , what about something like this ?
> 
> HAS_MODIFIED_ECLASS=$( find /usr/portage/eclass/ -name "*.eclass" -and
> -ctime "-1" -mtime "-1" )
> if [[ -z  $HAS_MODIFIED_ECLASS ]] ; then
>   echo "Good, using faster method"   
>   find /usr/portage -name "*.ebuild" \
>   -and -mtime "-1" \
>   -or -ctime "-1" \
>   -exec something_here.sh
> else
>   find /usr/portage -name "*.ebuild" \
>   -exec something_here.sh
> fi
> 
> will save you often, eclasses are not so frequently updated ;-)
Actually... :)

bit easier, abusing portage's own functionality.

python -c $'
import portage, time
target=long(time.strftime("%s",time.gmtime())) - 24*60*60
pdb=portage.portdb
for cp in pdb.cp_all():
	for cpv in pdb.cp_list(cp):
		flagged=False
		try:	mtime, eclasses = pdb.aux_get(cpv,["_mtime_","INHERITED"])
		except SystemExit:	raise
		except:	continue
		if mtime >= target:	flagged=True
		else:
			try:
				for e in eclasses.split():
					if pdb.eclassdb.eclasses[e][1] >= target:
						flagged=True
						break
			except KeyError:	flagged=True
		if flagged:	print cpv
'

~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] why do different ebuilds have the same version number?

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Slightly shorter variant...

python -c $'
import portage, time
from itertools import chain, imap
target=long(time.strftime("%s",time.gmtime())) - 24*60*60
pdb=portage.portdb
for cpv in chain(*imap(pdb.cp_list, pdb.cp_all())):
	flagged=False
	try:	mtime, eclasses = pdb.aux_get(cpv,["_mtime_","INHERITED"])
	except SystemExit:	raise
	except:	continue
	if mtime >= target:	flagged=True
	else:
		try:
			for e in eclasses.split():
				if pdb.eclassdb.eclasses[e][1] >= target:
					flagged=True
					break
		except KeyError:	flagged=True
	if flagged:	print cpv
'

~brian


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]