Patchwork dropbear: bump epoch to fix upgrade path in meta-oe

login
register
mail settings
Submitter Otavio Salvador
Date Dec. 15, 2011, 1:08 p.m.
Message ID <1323954515-15604-1-git-send-email-otavio@ossystems.com.br>
Download mbox | patch
Permalink /patch/17031/
State New
Headers show

Comments

Otavio Salvador - Dec. 15, 2011, 1:08 p.m.
There was a 'dropbear-systemd' binary package on meta-oe versioned as
'v1' and it has been merged on dropbear's bbappend; to fix the upgrade
path for the dropbear-systemd package on meta-oe we need to bump epoch
and to avoid messing it up this needs to go into OE-Core.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/recipes-core/dropbear/dropbear.inc |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
Phil Blundell - Dec. 15, 2011, 1:11 p.m.
On Thu, 2011-12-15 at 13:08 +0000, Otavio Salvador wrote:
> There was a 'dropbear-systemd' binary package on meta-oe versioned as
> 'v1' and it has been merged on dropbear's bbappend; to fix the upgrade
> path for the dropbear-systemd package on meta-oe we need to bump epoch
> and to avoid messing it up this needs to go into OE-Core.

If it's just a single output binary at issue then setting PKGE for that
one package would be less disruptive.  I must admit I don't fully
understand why this needs to be in oe-core at all though: what exactly
is the "messing up" that would happen otherwise?

p.
Otavio Salvador - Dec. 15, 2011, 1:14 p.m.
On Thu, Dec 15, 2011 at 11:11, Phil Blundell <philb@gnu.org> wrote:

> On Thu, 2011-12-15 at 13:08 +0000, Otavio Salvador wrote:
> > There was a 'dropbear-systemd' binary package on meta-oe versioned as
> > 'v1' and it has been merged on dropbear's bbappend; to fix the upgrade
> > path for the dropbear-systemd package on meta-oe we need to bump epoch
> > and to avoid messing it up this needs to go into OE-Core.
>
> If it's just a single output binary at issue then setting PKGE for that
> one package would be less disruptive.  I must admit I don't fully
> understand why this needs to be in oe-core at all though: what exactly
> is the "messing up" that would happen otherwise?
>

I didn't know about PKGE; this works for this case :-D

Richard, please ignore this patch!
Otavio Salvador - Dec. 15, 2011, 1:45 p.m.
On Thu, Dec 15, 2011 at 11:14, Otavio Salvador <otavio@ossystems.com.br>wrote:

> On Thu, Dec 15, 2011 at 11:11, Phil Blundell <philb@gnu.org> wrote:
>>
>> If it's just a single output binary at issue then setting PKGE for that
>> one package would be less disruptive.  I must admit I don't fully
>> understand why this needs to be in oe-core at all though: what exactly
>> is the "messing up" that would happen otherwise?
>>
>
> I didn't know about PKGE; this works for this case :-D
>

It seems setting:

PKGE_${PN}-systemd = "1" in the bbappend doesn't work.

Any clue?

Patch

diff --git a/meta/recipes-core/dropbear/dropbear.inc b/meta/recipes-core/dropbear/dropbear.inc
index 1894715..073ac13 100644
--- a/meta/recipes-core/dropbear/dropbear.inc
+++ b/meta/recipes-core/dropbear/dropbear.inc
@@ -11,6 +11,8 @@  DEPENDS = "zlib"
 RPROVIDES = "ssh sshd"
 DEPENDS += "${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
 
+PE = "1"
+
 SRC_URI = "http://matt.ucc.asn.au/dropbear/releases/dropbear-${PV}.tar.gz \
 	         file://urandom-xauth-changes-to-options.h.patch \
 		 file://dropbear-0.53.1-static_build_fix.patch \