Re: Problem with debian renaming and upgrade-path on dora

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

On Fri, Aug 01, 2014 at 10:32:38AM +0100, Paul Eggleton wrote:
> Hi Henning,
> 
> On Tuesday 29 July 2014 19:32:51 Henning Heinold wrote:
> > I have a problem to get a sane upgrade path for a library package which
> > should be splitted in to serval packages on dora.
> > 
> > The old package is called libfoo now the package gets split into libfoo
> > libfoo-bar libfoo-set and so on.
> > 
> > Because of the debian renaming for libraries the PN-library package libfoo
> > is renamed to libfoo3.
> > 
> > If we now want to upgrade from libfoo to libfoo3 oneway would be to use
> > RREPLACE, but the renaming wrapping is written at do_package into files,
> > before all the other stuff kicks in.
> > 
> > So all RREPLACES are renamed to libfoo3 too, making it impossible to get a
> > REPLACE stanza for libfoo into an ipk.

Why do you want to do the upgrade one-way?

I think that one of debian renaming benefits is that the old libfoo
package stays installed on target until all programs aren't rebuilt
against libfoo3 and upgraded - then old libfoo could be automatically
uninstalled as orphaned package.

> Hmm. I guess one workaround for this would be to set the RREPLACES / RPROVIDES 
> / RCONFLICTS in a Python function that is called after the debian renaming 
> happens.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]