[CentOS-devel] CentOS-[56] Continous Release

Thu Jun 2 13:24:26 UTC 2011
Lamar Owen <lowen at pari.edu>

On Thursday, June 02, 2011 08:53:49 AM Ralph Angenendt wrote:
> That might be hard to do, as the only working thing coming to my mind is
> adding to the R of NEVR - and what happens if that package doesn't get
> updated ever after that? You'll then have that release/repo tag for the
> rest of the package's lifetime. Reissuing the package within the point
> release might not work then either, if rpm/yum doesn't deem the then
> released package to be newer than the "rolling" package.

And this is a problem 'developed' (as opposed to 'rebuilt') distributions don't have.....  The mantra there is simply 'NEVR must change if the package changes in any way, shape, form, or build' and that eliminates the problem for 'developed' distributions.

> Or did you have something else in mind?

:-)

yum-plugin-rolling-rebuild.  Wish I had such written....or even specified.... A yum plugin that compares something unique between packages with identical NEVR tuples, but also something that is present in the repo files and is carried into the rpm database.  Would be a prerequisite for successfully using CR in a seamless fashion, methinks.

Since the build time (field 'time_build') is present in the repo metadata, perhaps this plugin could force a reinstall during 'yum update' of package(s) whose time_build has changed.  But is time_build carried over from the yum sqlite repo databases to the rpm databases?  That I don't know, and my Berkely db skills aren't even close to my SQL skills....   So finding something that will tag the package as having changed even though NEVR has not changed, and that the plugin can then verify properly and then issue the reinstall of that package as part of the update is what is needed for this specific use case.

Ok, looking at possibilities, the yum repo data field 'time_build' might just work, since RPM apparently does store that information:
[root at migration base]# rpm -qa --queryformat="%{NAME} %{BUILDTIME} \n"|head
gnome-audio 1168123179 
libICE 1168062878 
libjpeg 1168063870 
info 1173922742 
libattr 1168060218 
libxslt 1217530262 
libogg 1173898173 
readline 1253572717 
gmp 1173887159 
libattr 1168060345 
[root at migration base]# 

Thoughts?