* RFC: Versioning of git recipes (and incremental PR)
@ 2012-11-23 17:26 Richard Purdie
2012-11-23 19:23 ` Otavio Salvador
0 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2012-11-23 17:26 UTC (permalink / raw)
To: bitbake-devel, openembedded-core; +Cc: Constantin Musca
Currently we have some rather complex and potentially broken code in the
fetcher code to deal with the the fact that you don't get incremental
versions from git revisions easily. The system currently has a database
and generates incremental numbers so PV becomes something like:
0.1+git1-deadbeefdecafbad
or for perverse recipes with more than one git source:
0.1+git1-deadbeefdecafbad-git3-decafbaddeadbeef
We currently have a bug that this doesn't interact well with sstate
feeds since you have to have a single persistdb for any given sstate
feed. It won't break in that sstate will just not be used but that is
inefficient.
The fact we need to have increasing values in the field is a very
similar problem to the incremental PR for package fields that we're
addressing with the PR server.
I've therefore taken a step back and considered things and am proposing
that we adapt the PR server to handle this issue and then drop the code
from the fetcher. The rough implementation of this would mean that:
* PV would become 0.1+gitAUTOINC-deadbeefdecafbad-decafbaddeadbeef
* We'd have one incrementing value rather than several.
* That the code would detect a PV containing AUTOINC and set PKGV to the
same thing with AUTOINC replaced with the "auto PR" value
* We'd do this in parallel with the usual auto PR value. In PR server
terms this means likely in the same data table using "git-PV" as the key
and just call the API with a different key name.
* If the PR server isn't running, this would just set PKGV to PV but
with AUTOINC set to 0. This would mean you wouldn't get updating package
feeds but usual image creation would be just fine.
* There are some complexities for data import and export we need to
consider and work through.
All things considered I think this would be a nice improvement and allow
us to have one good set of "incremental" code and simplify the fetchers.
I'm open to discussion... :)
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Versioning of git recipes (and incremental PR)
2012-11-23 17:26 RFC: Versioning of git recipes (and incremental PR) Richard Purdie
@ 2012-11-23 19:23 ` Otavio Salvador
2012-11-23 19:45 ` Richard Purdie
0 siblings, 1 reply; 6+ messages in thread
From: Otavio Salvador @ 2012-11-23 19:23 UTC (permalink / raw)
To: Richard Purdie; +Cc: bitbake-devel, Constantin Musca, openembedded-core
On Fri, Nov 23, 2012 at 3:26 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Currently we have some rather complex and potentially broken code in the
> fetcher code to deal with the the fact that you don't get incremental
> versions from git revisions easily. The system currently has a database
> and generates incremental numbers so PV becomes something like:
>
> 0.1+git1-deadbeefdecafbad
>
> or for perverse recipes with more than one git source:
>
> 0.1+git1-deadbeefdecafbad-git3-decafbaddeadbeef
>
> We currently have a bug that this doesn't interact well with sstate
> feeds since you have to have a single persistdb for any given sstate
> feed. It won't break in that sstate will just not be used but that is
> inefficient.
>
> The fact we need to have increasing values in the field is a very
> similar problem to the incremental PR for package fields that we're
> addressing with the PR server.
Yes; I had problem using GIT with PR server last time I tried it.
Good that it's being worked on/has been fixed.
> I've therefore taken a step back and considered things and am proposing
> that we adapt the PR server to handle this issue and then drop the code
> from the fetcher. The rough implementation of this would mean that:
>
> * PV would become 0.1+gitAUTOINC-deadbeefdecafbad-decafbaddeadbeef
>
> * We'd have one incrementing value rather than several.
>
> * That the code would detect a PV containing AUTOINC and set PKGV to the
> same thing with AUTOINC replaced with the "auto PR" value
>
> * We'd do this in parallel with the usual auto PR value. In PR server
> terms this means likely in the same data table using "git-PV" as the key
> and just call the API with a different key name.
>
> * If the PR server isn't running, this would just set PKGV to PV but
> with AUTOINC set to 0. This would mean you wouldn't get updating package
> feeds but usual image creation would be just fine.
>
> * There are some complexities for data import and export we need to
> consider and work through.
>
> All things considered I think this would be a nice improvement and allow
> us to have one good set of "incremental" code and simplify the fetchers.
>
> I'm open to discussion... :)
I like to idea of a single updating place. What I dislike is AUTOINC
not being taken care in the fetcher.
In this case any GIT revision changes, the AUTOINC won't bump as usual
(without PR server)?
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Versioning of git recipes (and incremental PR)
2012-11-23 19:23 ` Otavio Salvador
@ 2012-11-23 19:45 ` Richard Purdie
2012-11-24 13:55 ` Otavio Salvador
0 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2012-11-23 19:45 UTC (permalink / raw)
To: Otavio Salvador; +Cc: bitbake-devel, Constantin Musca, openembedded-core
On Fri, 2012-11-23 at 17:23 -0200, Otavio Salvador wrote:
> I like to idea of a single updating place. What I dislike is AUTOINC
> not being taken care in the fetcher.
>
> In this case any GIT revision changes, the AUTOINC won't bump as usual
> (without PR server)?
Why do you need AUTOINC to bump? The only reason we have increments in
the fetcher is for package upgrading...
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Versioning of git recipes (and incremental PR)
2012-11-23 19:45 ` Richard Purdie
@ 2012-11-24 13:55 ` Otavio Salvador
2012-11-25 21:21 ` Richard Purdie
0 siblings, 1 reply; 6+ messages in thread
From: Otavio Salvador @ 2012-11-24 13:55 UTC (permalink / raw)
To: Richard Purdie; +Cc: bitbake-devel, Constantin Musca, openembedded-core
On Fri, Nov 23, 2012 at 5:45 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2012-11-23 at 17:23 -0200, Otavio Salvador wrote:
>> I like to idea of a single updating place. What I dislike is AUTOINC
>> not being taken care in the fetcher.
>>
>> In this case any GIT revision changes, the AUTOINC won't bump as usual
>> (without PR server)?
>
> Why do you need AUTOINC to bump? The only reason we have increments in
> the fetcher is for package upgrading...
Yes but in this case the fetcher won't change AUTOINC and you'll have
same revision even when changing SRCREVs. This will break the upgrade
path for people not using PR server, no?
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Versioning of git recipes (and incremental PR)
2012-11-24 13:55 ` Otavio Salvador
@ 2012-11-25 21:21 ` Richard Purdie
2012-11-25 21:44 ` Otavio Salvador
0 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2012-11-25 21:21 UTC (permalink / raw)
To: Otavio Salvador; +Cc: bitbake-devel, Constantin Musca, openembedded-core
On Sat, 2012-11-24 at 11:55 -0200, Otavio Salvador wrote:
> On Fri, Nov 23, 2012 at 5:45 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Fri, 2012-11-23 at 17:23 -0200, Otavio Salvador wrote:
> >> I like to idea of a single updating place. What I dislike is AUTOINC
> >> not being taken care in the fetcher.
> >>
> >> In this case any GIT revision changes, the AUTOINC won't bump as usual
> >> (without PR server)?
> >
> > Why do you need AUTOINC to bump? The only reason we have increments in
> > the fetcher is for package upgrading...
>
> Yes but in this case the fetcher won't change AUTOINC and you'll have
> same revision even when changing SRCREVs. This will break the upgrade
> path for people not using PR server, no?
We're going to need the PR server for upgrade paths in future regardless
so that shouldn't be an issue.
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Versioning of git recipes (and incremental PR)
2012-11-25 21:21 ` Richard Purdie
@ 2012-11-25 21:44 ` Otavio Salvador
0 siblings, 0 replies; 6+ messages in thread
From: Otavio Salvador @ 2012-11-25 21:44 UTC (permalink / raw)
To: Richard Purdie; +Cc: bitbake-devel, Constantin Musca, openembedded-core
On Sun, Nov 25, 2012 at 7:21 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Sat, 2012-11-24 at 11:55 -0200, Otavio Salvador wrote:
>> On Fri, Nov 23, 2012 at 5:45 PM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> > On Fri, 2012-11-23 at 17:23 -0200, Otavio Salvador wrote:
>> >> I like to idea of a single updating place. What I dislike is AUTOINC
>> >> not being taken care in the fetcher.
>> >>
>> >> In this case any GIT revision changes, the AUTOINC won't bump as usual
>> >> (without PR server)?
>> >
>> > Why do you need AUTOINC to bump? The only reason we have increments in
>> > the fetcher is for package upgrading...
>>
>> Yes but in this case the fetcher won't change AUTOINC and you'll have
>> same revision even when changing SRCREVs. This will break the upgrade
>> path for people not using PR server, no?
>
> We're going to need the PR server for upgrade paths in future regardless
> so that shouldn't be an issue.
Yes I agree but in this case this change would need to wait for PR
server to be the default before be applied.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-11-26 11:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-23 17:26 RFC: Versioning of git recipes (and incremental PR) Richard Purdie
2012-11-23 19:23 ` Otavio Salvador
2012-11-23 19:45 ` Richard Purdie
2012-11-24 13:55 ` Otavio Salvador
2012-11-25 21:21 ` Richard Purdie
2012-11-25 21:44 ` Otavio Salvador
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox