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@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@migration base]#
Thoughts?