Bug 2787

Summary:	buildhistory.bbclass should track runtime package name changes
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Martin Jansa <Martin.Jansa>
Component:	core	Assignee:	Paul Eggleton <bluelightning>
Status:	VERIFIED FIXED	QA Contact:
Severity:	enhancement
Priority:	Low	CC:	alexandrux.palalau, bluelightning, jessica.zhang, meta.mr.watcher, meta.watcher
Version:	unspecified
Target Milestone:	1.3 M4
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	---

Description Martin Jansa 2012-07-18 09:45:04 UTC

buildhistory is great tool to test metadata changes to see if they have some unexpected packaging side-effects.

One of common side-effects is that new recipe version includes new binary/lib in package and without LEAD_SONAME we don't get runtime package named as it was before (when using debian.bbclass). 

Or when .so version is changed and e.g. libudev0 package is renamed to libudev1.

Such changes should be clearly documented by buildhistory.

Now there is only buildtime name (e.g. libudev) and 
packages/armv7a-vfp-neon-oe-linux-gnueabi/udev/libudev/latest doesn't show if it's called libudev0 or libudev1 in runtime (also base of .ipk filename).

If possible add
RUNTIME_NAME = "libudev0"
to latest file, or something like that

Comment 1 Martin Jansa 2012-07-20 13:08:30 UTC

Also runtime version (PKGV) should be tracked..

e.g. systemd is using gitpkgv class for consistent git versions across multiple builders (without need to synchronize cache/bb_persist_data.sqlite3)

inherit gitpkgv
PKGV = "v${GITPKGVTAG}"
PV = "git"

And when SRCREV was upgraded to newer version (with newer GITPKGVTAG) together with PR reset it was incorrectly reporting:

ERROR: Package version for package systemd went backwards which would break package feeds from (0:git-r32 to 0:git-r5)

but from package manager POV it was normal upgrade..

Comment 2 Paul Eggleton 2012-08-06 14:51:29 UTC

Implementation merged in Poky revision 06ad59cca92f58d4eefa42b532a778f3b83c66a1.

Comment 3 Alexandru Palalau 2012-10-17 12:10:04 UTC

Verified on danny and master branches