RFC: Versioning of git recipes (and incremental PR)
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
Quoted 11 lines · Richard Purdie
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
Quoted 8 lines
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.
Quoted 19 lines
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.
Quoted 7 lines
* 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)?
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Quoted 5 lines · Otavio Salvador
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
Quoted 9 lines · Richard Purdie
Quoted 5 lines · Otavio Salvador
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?
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Quoted 9 lines · Otavio Salvador
Quoted 7 lines · Richard Purdie
Quoted 5 lines · Otavio Salvador
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)?
Quoted 6 lines
Quoted 2 lines
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
Quoted 13 lines · Richard Purdie
Quoted 12 lines · Otavio Salvador
Quoted 9 lines · Richard Purdie
Quoted 5 lines · Otavio Salvador
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...
Quoted 6 lines
Quoted 3 lines
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.
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br