All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: PRINC migration questions
Date: Fri, 7 Nov 2014 15:36:18 +0100	[thread overview]
Message-ID: <20141107143618.GE2444@jama> (raw)
In-Reply-To: <e111da9e0a424a2eac00f684ba4da94f@BY2PR05MB048.namprd05.prod.outlook.com>

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

On Fri, Nov 07, 2014 at 01:31:02PM +0000, Bryan Evenson wrote:
> All,
> 
> I am on poky/dylan and have not yet started using the PR server.  I really do want to start using the PR server and stop using PRINC.  However, even more so I really don't want to break my package feeds.  I want to make sure I do my migration correctly and I don't do something that looks like it works okay only to find out it causes problems later.  With that in mind, I am looking for advice on the proper way to migrate away from using PRINC.
> 
> Let's say I have a .bbappend in my private layer with the line:
> 
> PRINC := "${@int(PRINC) + 4}"
> 
> The mainline layer's .bb has the line:
> 
> PR = "${INC_PR}.0"
> 
> And the mainline layer's .inc has the line:
> 
> INC_PR = "r8"
> 
> In this scenario, the resulting PR will be "r12.0".  Now let's say I want to start using the PR server and get rid of PRINC in this recipe.  The resulting package contents are to be the same, so I want the resulting PR to be "r12.0".  From some limited testing, if I start the PR server and remove the PRINC line from my .bbappend the resulting PR is "r8.0".  So in my .bbappend should I change the PRINC line to:
> 
> INC_PR = "r12"
> 
> Or should I change it to something else?  If I change it to a hardcoded value, then I'll have to be careful about what to do if the mainline recipe changes INC_PR.  How have other people handled this situation?

PR service won't you help at all with this (it adds another .N to PR
value, so it cannot fix when the level of .N goes backwards).

The only really working solution is to increment INC_PR/PR values in upstream
recipes atomically with PRINC drop in your layers.

For PR service migration the more important part is to correctly migrate
LOCALCOUNT numbers (used in SRCPVs), especially if you're also changing
package architecture (e.g. t2 suffix added in daisy or selecting
different DEFAULTTUNE and all your LOCALCOUNTs in PR server DB will
reset to 0, because of different db key to find them. Luckily you can
pre-populate them with single SQL command if you realize this situation
before first build.

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

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

  reply	other threads:[~2014-11-07 14:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07 13:31 PRINC migration questions Bryan Evenson
2014-11-07 14:36 ` Martin Jansa [this message]
2014-11-07 15:36   ` Bryan Evenson
2014-11-07 23:20     ` Martin Jansa
2014-11-10 14:39       ` Bryan Evenson
2014-11-07 15:46 ` Michael_E_Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141107143618.GE2444@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.