[oe] SRCPV migration

[Martin Jansa]

On Mon, Nov 16, 2009 at 01:19:15PM +0100, Koen Kooi wrote:
> On 16-11-09 12:51, Martin Jansa wrote:
> >On Mon, Nov 16, 2009 at 11:59:10AM +0100, Koen Kooi wrote:
> >>On 16-11-09 11:49, Richard Purdie wrote:
> >>>On Mon, 2009-11-16 at 11:37 +0100, Koen Kooi wrote:
> >>>>So basically every recipe that is using SRCPV in PV or PR is unsuitable
> >>>>to be put in online feeds. That should be enough to stop the SRCPV merge
> >>>>into .dev.
> >>>
> >>>How is this different to the current situation though?
> >>
> >>In the current situation (actually, last weeks situation) SRCPV was
> >>never used.
> >>
> >>>If SRCREV is locked down you will get 1 as the local build revision back
> >>>and it will not change and will be the same for everyone.
> >>
> >>>If its not locked down, all bets are off but they always have been - no
> >>>change.
> >>
> >>Ah, that was the bit of info I was missing. But if SRCREV is locked
> >>down (as it should!) what's the point of putting SRCPV in PV or PR?
> >>It seems to make things worse if you update a locked SRCREV, since
> >>SRCPV will remain '1'.
> >>
> >>regards,
> >>
> >>Koen
> >
> >Hi,
> >
> >I'm not sure if this is 100% right but it behaves like this here:
> >
> >with AUTOREV used
> 
> Which angstrom tries to avoid at great lenghts and any OE recipe
> fetched from an scm will by default and policy have a locked down
> rev available.
> A user (or distro) has to explicitly enable AUTOREV for recipes.

Sure, but AUTOREV is still usefull for recipes which are ie distro
specific (ie shr telephony stack) which is still developing pretty fast
and no one would like to see SRCREV bumps twice a day just because
developers are still fixing bugs in that package and users want bleeding
edge version for their distribution.

But once development slows down, would be nice to easily switch to fixed
SRCREV with upgradeable PV.

> >as SRCREV you get ${SRCREV} in format
> >gitrNNNN+hash
> >where NNNN is localcount incremented on buildhost every time you build
> >that recipe AND hash is changed
> >if you have fixed SRCREV then without SRCPV you get just gitrHash which
> >can be<  gitrNNNN+hash or>  gitrNNNN+hash depending on actual hash value.
> >That's why you cannot switch between SRCREV and SRCPV without PE bump.
> 
> I'm extremely allergic to PE bumps, because it means we screwed up big time.
> 
> >If there is SRCPV in PV and you're using fixed SRCREV than you don't
> >need to bump PR in cases like this
> >./xorg-proto/calibrateproto_git.bb:PV = "0.0+${PR}+gitr${SRCPV}"
> >because +gitr${SRCPV} will create non-decreasing sequence as localcount
> >will be incremented every time you bump fixed SRCREV for that recipe AND
> >build it.
> 
> So, how do I say
> 
> PREFERRED_VERSION_calibrateproto = 0.0+r1+gitr483843874931943189393
> # (4838... is what's in sane-srcrevs.inc)

This is imho wrong by design as you need to update SRCREV in sane-srcrevs 
or recipe then bump PR and then check if there is
PREFERRED_VERSION_calibrateproto for any distribution even outside OE
repo, because otherwise preferred version won't exist anymore and maybe 
even lower version will be picked (ie if there is DEFAULT_PREFERENCE = "-1" 
in that git recipe)?

That's why I proposed wildcard character to PREFERRED_VERSION before in 
http://patchwork.openembedded.org/patch/1057/

BTW: what about using something like this
PV = "0.0+git"
PR = "${INC_PR}.1+gitr${SRCPV}"

would be easy to set PREFERRED_VERSION to constant string "0.0+git"

> with SRCPV? It seems I would loose the ability to do that 'globally'
> since SRCPV is tied to a buildhost.
> 
> >You're right that there can be inconsistency between builders if one ie
> >you're changing fixed srcrev every day and rebuild it on that buildhost
> >and othere buildhost is rebuilding that package once a month.
> >
> >If all your builders are building all your targets every day and you're
> >not changing fixed SRCREV more then once a day, you need to sync
> >bb_persist_data.sqlite3 only for new builder or after some failures
> >(which I know is quite error-prone :().
> 
> So SRCPV makes things worse than the current situation.

switching AUTOREV <-> fixed SRCREV is not possible at all now, you even
need PE bump when switching, which is IMHO worse.

> >This inconsistency can be fixed imho only by sharing
> >tmpdir-dev-shr/cache/om-gta02/bb_persist_data.sqlite3 between hosts
> >(better using some online database access for getting localcounts)
> >
> >sqlite3 ../tmpdir-dev-shr/cache/om-gta02/bb_persist_data.sqlite3
> >"select * from BB_URI_LOCALCOUNT where key like '%kernel.git-linux-openmoko-shr-drm-devel_count';"
> >git:git.openmoko.org.git.kernel.git-linux-openmoko-shr-drm-devel_count|5
> 
> So it seems that using SRCPV in PV and PR shouldn't be allowed till
> there is *good* way to share the 'localcount' to all builders.

I like RP's idea about dropping localcount for distros never using
AUTOREV. Only change for you then would be gitr0+Hash instead gitrHash
which isn't that bad, is it?

> regards,

regards,

-- 
uin:136542059                jid:Martin.Jansa at gmail.com
Jansa Martin                 sip:jamasip at voip.wengo.fr 
JaMa