On Thu, 2011-03-24 at 09:55 -0400, Lamar Owen wrote:
> On Thursday, March 24, 2011 08:51:30 am Les Mikesell wrote:
> > Also note that you can't just 'yum update' from those SL alpha versions to the
> > final release, so even if CentOS did ship alpha/beta versions it wouldn't make
> > life that much easier.
>
> The problem with updates from a rolling alpha/beta to the GA release
> is that it is possible that the package contents change but the
> epoch:version-release tuple doesn't; especially given a rebuild of the
> upstream source package (which cannot have its EVR changed and
> maintain strict compatibility) due to things like the libtalloc
> versioning situation previously mentioned.
This is kind of a unique situation, in that it's pretty well accepted
that if you are rebuilding for any reason you need to change at least
the release in some way.
I kind of understand why you don't want to, but I'm not sure it's worth
the problem of having M versions of a particular NEVRA. Does this happen
anytime after initial distro. creation?
> I haven't checked to see if it's implemented in EL6, but this sounds
> like a situation tailor-made for yum distro-sync. I'm not sure,
> however, how distro-sync acts when packages are actually different but
> their EVR stays the same.
As above, we currently mostly only look at NEVRA for identifying
packages in any part of yum.
For rpmdbv's we also look at the checksum, so I had thought about doing
something so you could more easily "reinstall" anything with changed
checksums:
import yum
yb = yum.YumBase()
for ipkg in sorted(yb.rpmdb):
for apkg in yb.pkgSack.searchPkgTuple(ipkg.pkgtup):
if ('checksum_type' in ipkg.yumdb_info and
'checksum_data' in ipkg.yumdb_info):
if ipkg.yumdb_info.checksum_data != apkg.pkgId:
print "Diff chksum:", ipkg, ipkg.ui_from_repo, apkg.repoid
print " :", ipkg, ipkg.yumdb_info.checksum_type, ipkg.yumdb_info.checksum_data
print " :", apkg, apkg.checksum_type, apkg.pkgId
else:
print "No chksum:", ipkg, ipkg.ui_from_repo, apkg.repoid
...that does have some minor downsides though. For instance changing the
repo. from "sha" to sha256 would fake the above into reinstalling
everything (but then again, doing that would break rpmdbv compatibility,
and so would be very bad). It also currently changes if the signing key
changes, but again you'd probably want that.
Probably the most significant downside is that you can't sort based on
that, you can only tell that X is different from Y not which is
preferred but then I'd _really_ want to discourage people publishing
multiple NEVRAs that are identical ... and one assumes that when you are
doing your builds you rarely (if ever?) want to go backwards.
In theory we could also use "buildtime", but I'm very wary of making
that into a minor release id as it would encourage the multiple NEVRAs
problem and it is much less linear in other distributions (although
they'd tend to respect NEVRA :).
Also worth noting is that the one NEVRA dup. with different checksums I
can see on F13 is libjingle in updates and fedora-chromium ... and those
have the same buildtime (I assume spot just resigned it).