Tom Zanussi : lttng2-ust: rename to lttng-ust
A message that is not in the archive (sent off-list or not yet received): 20130116115800.A69171034D@opal
Quoted 10 lines · On Wed, Jan 16, 2013 at 11:58:00AM +0000, [email protected] wrote:
Module: openembedded-core.git Branch: master Commit: 3c927c39502061bdf3ef9fba1f0f6e7080f6c3cd URL: http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=3c927c39502061bdf3ef9fba1f0f6e7080f6c3cdAuthor: Tom Zanussi <[email protected]> Date: Fri Jan 11 17:28:47 2013 -0600lttng2-ust: rename to lttng-ust
Quoted 8 lines
recipes-kernel/lttng/lttng-ust was removed by a previous patch, which also removed the naming conflict that caused the lttng-2.0 version of lttng-ust to be named lttng2-ust. lttng2-ust was the only lttng-2.0 recipe to be named in this way and since that was entirely due to the conflict, we can go back to the consistent naming for it.
Signed-off-by Tom Zanussi <[email protected]>Signed-off-by Saul Wold <[email protected]>
lttng-ust had PE="1", bump PE to fix upgrade path:
ERROR: Package version for package lttng-ust-dbg went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-staticdev went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-dev went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-doc went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-locale went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
Quoted 59 lines
---
.../packagegroup-core-tools-profile.bb | 2 +- meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb | 2 +- .../{lttng2-ust_2.1.0.bb => lttng-ust_2.1.0.bb} | 5 +++++ 3 files changed, 7 insertions(+), 2 deletions(-)meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb +1
-1@@ -46,7 +46,7 @@ SYSTEMTAP_aarch64 = "" # which means we can not use syscall() to call it. So we ignore # it for x86_64/uclibc -LTTNGUST = "lttng2-ust" +LTTNGUST = "lttng-ust" LTTNGUST_libc-uclibc = "" LTTNGUST_mips = "" LTTNGUST_aarch64 = ""meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb +1
-1@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \ file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca" -DEPENDS = "liburcu popt lttng2-ust" +DEPENDS = "liburcu popt lttng-ust" SRCREV = "917f768512b5d336d553b801f6c5308d90252a89" PV = "v2.1.0"meta/recipes-kernel/lttng-2.0/lttng-ust_2.1.0.bb renamed from meta/recipes-kernel/lttng-2.0/lttng2-ust_2.1.0.bb +5
-0@@ -12,6 +12,11 @@ inherit autotools DEPENDS = "liburcu util-linux" +# For backwards compatibility after rename +RPROVIDES_${PN} = "lttng2-ust" +RREPLACES_${PN} = "lttng2-ust" +RCONFLICTS_${PN} = "lttng2-ust" + SRCREV = "0c9ad44b7604040dfcd1e67b18afc3dc5d025b19" PV = "2.1.0" PR = "r0"_______________________________________________
Openembedded-commits mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 20 lines · Martin Jansa
Quoted 10 lines · On Wed, Jan 16, 2013 at 11:58:00AM +0000, [email protected] wrote:
Module: openembedded-core.git Branch: master Commit: 3c927c39502061bdf3ef9fba1f0f6e7080f6c3cd URL: http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=3c927c39502061bdf3ef9fba1f0f6e7080f6c3cdAuthor: Tom Zanussi <[email protected]> Date: Fri Jan 11 17:28:47 2013 -0600lttng2-ust: rename to lttng-ust
Quoted 8 lines
recipes-kernel/lttng/lttng-ust was removed by a previous patch, which also removed the naming conflict that caused the lttng-2.0 version of lttng-ust to be named lttng2-ust. lttng2-ust was the only lttng-2.0 recipe to be named in this way and since that was entirely due to the conflict, we can go back to the consistent naming for it.
Signed-off-by Tom Zanussi <[email protected]>Signed-off-by Saul Wold <[email protected]>
Quoted 9 lines
lttng-ust had PE="1", bump PE to fix upgrade path:
ERROR: Package version for package lttng-ust-dbg went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-staticdev went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-dev went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-doc went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-locale went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
Thanks for the report - I just sent a patch to fix this.
Tom
Quoted 60 lines
Quoted 59 lines
---
.../packagegroup-core-tools-profile.bb | 2 +- meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb | 2 +- .../{lttng2-ust_2.1.0.bb => lttng-ust_2.1.0.bb} | 5 +++++ 3 files changed, 7 insertions(+), 2 deletions(-)meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb +1
-1@@ -46,7 +46,7 @@ SYSTEMTAP_aarch64 = "" # which means we can not use syscall() to call it. So we ignore # it for x86_64/uclibc -LTTNGUST = "lttng2-ust" +LTTNGUST = "lttng-ust" LTTNGUST_libc-uclibc = "" LTTNGUST_mips = "" LTTNGUST_aarch64 = ""meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb +1
-1@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \ file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca" -DEPENDS = "liburcu popt lttng2-ust" +DEPENDS = "liburcu popt lttng-ust" SRCREV = "917f768512b5d336d553b801f6c5308d90252a89" PV = "v2.1.0"meta/recipes-kernel/lttng-2.0/lttng-ust_2.1.0.bb renamed from meta/recipes-kernel/lttng-2.0/lttng2-ust_2.1.0.bb +5
-0@@ -12,6 +12,11 @@ inherit autotools DEPENDS = "liburcu util-linux" +# For backwards compatibility after rename +RPROVIDES_${PN} = "lttng2-ust" +RREPLACES_${PN} = "lttng2-ust" +RCONFLICTS_${PN} = "lttng2-ust" + SRCREV = "0c9ad44b7604040dfcd1e67b18afc3dc5d025b19" PV = "2.1.0" PR = "r0"_______________________________________________
Openembedded-commits mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits
Quoted 1 line · Tom Zanussi
Quoted 1 line
lttng-ust had PE="1", bump PE to fix upgrade path:
Technically, that isn't going to "fix" the upgrade path. lttng 1.x requires kernel patches and isn't compatible with lttng 2.x, as far as I'm aware. So any machine with lttng 1.x that upgrades to this wouldn't be a real 'upgrade', it would switch interfaces, and potentially break compatibility with the kernel running on that device. At mentor we have bsp layers for 1.x and for 2.x, and both work. I'm glad we aren't binary package feed based, or we'd be in serious trouble with this.
Signature · 1 line
Christopher Larson
Quoted 5 lines · Chris Larson
On Wed, Jan 16, 2013 at 8:38 AM, Tom Zanussi <[email protected]> wrote:
> lttng-ust had PE="1", bump PE to fix upgrade path:
Quoted 9 lines
Technically, that isn't going to "fix" the upgrade path. lttng 1.x requires kernel patches and isn't compatible with lttng 2.x, as far as I'm aware. So any machine with lttng 1.x that upgrades to this wouldn't be a real 'upgrade', it would switch interfaces, and potentially break compatibility with the kernel running on that device. At mentor we have bsp layers for 1.x and for 2.x, and both work. I'm glad we aren't binary package feed based, or we'd be in serious trouble with this.
This is for the userspace tracing part, lttng-ust, which AFAIK doesn't require any kernel patches.
The other lttng 2.x recipes weren't changed, just moved, so that shouldn't break anything.
The lttng 1.x recipes were removed, however, since they do require extensive kernel patches, and at least the recent Yocto kernels didn't have those applied, mainly IIRC because the transition of the lttng project in the meantime to version 2.0 made that difficult. But now that 2.0 is available there doesn't seem to be a good reason to keep 1.x around especially considering the work involved in patching the kernel and the fact that the functionality is mostly replaced by 2.0.
Tom
Quoted 3 lines · Tom Zanussi
This is for the userspace tracing part, lttng-ust, which AFAIK doesn't require any kernel patches.
Yes, but the point was, as far as I know, the newer ust requires the newer kernel components, and the older requires the older kernel components, so technically the package upgrade on a device is likely to change the behavior.
I didn't say the current version required patches, the point was about the upgrade path for this recipe. I suspect we're one of the only companies that was actually using the old recipes, and we don't particularly care about the binary package upgrade paths at this time, but again, this is *not* a particularly smooth binary package upgrade path. I expect we're fine with that, but I wanted make sure it was an explicit conscious choice of behavior, not something unexpected.
Signature · 1 line
Christopher Larson
Quoted 11 lines · Chris Larson
Quoted 3 lines · Tom Zanussi
This is for the userspace tracing part, lttng-ust, which AFAIK doesn't require any kernel patches.
Yes, but the point was, as far as I know, the newer ust requires the newer kernel components, and the older requires the older kernel components, so technically the package upgrade on a device is likely to change the behavior.
Quoted 7 lines
I didn't say the current version required patches, the point was about the upgrade path for this recipe. I suspect we're one of the only companies that was actually using the old recipes, and we don't particularly care about the binary package upgrade paths at this time, but again, this is *not* a particularly smooth binary package upgrade path. I expect we're fine with that, but I wanted make sure it was an explicit conscious choice of behavior, not something unexpected.
From what you said it looks like recipe shouldn't be renamed in first place.
I'm not interested in lttng, first I was commenting only about recipe being renamed without RPROVIDES/RREPLEACES/RCONFLICTS combo and then I was surprised to see that ERROR about version downgrade from buildhistory.
Cheers,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 20 lines · Martin Jansa
Quoted 11 lines · Chris Larson
Quoted 3 lines · Tom Zanussi
This is for the userspace tracing part, lttng-ust, which AFAIK doesn't require any kernel patches.
Yes, but the point was, as far as I know, the newer ust requires the newer kernel components, and the older requires the older kernel components, so technically the package upgrade on a device is likely to change the behavior.
Quoted 7 lines
I didn't say the current version required patches, the point was about the upgrade path for this recipe. I suspect we're one of the only companies that was actually using the old recipes, and we don't particularly care about the binary package upgrade paths at this time, but again, this is *not* a particularly smooth binary package upgrade path. I expect we're fine with that, but I wanted make sure it was an explicit conscious choice of behavior, not something unexpected.
Quoted 3 lines
From what you said it looks like recipe shouldn't be renamed in first place.
You may be right and what's confusing things is that the new name of the lttng project actually includes the version number as part of its name despite it being a completely new project.
So I could submit a patch to rename lttng-ust back to lttng2-ust, but that would be inconsistent with the other packages in 'lttng2' - it would in that case make sense to rename them also to lttng2-prefixed
versions i.e. lttng2-modules, lttng2-tools. It does get kind of
awkward when lttng2 releases a version 3 though- we'd have an lttng2_ust_3.0 then. Or will we just rename everything to lttng3_* at that point, which if the lttng project doesn't do the same, means we'd have provide some kind of mapping to say that our lttng3 is actually lttng 2.0's 3.0 and so on...
Or we could just keep everything as lttng-*, rename the lttng2-ust now and just keep it that way in future regardless of what lttngX decides to name itself next time.
I'm happy to do either, depending on what people want..
Tom
Quoted 6 lines
I'm not interested in lttng, first I was commenting only about recipe being renamed without RPROVIDES/RREPLEACES/RCONFLICTS combo and then I was surprised to see that ERROR about version downgrade from buildhistory.
Cheers,