On Fri, Nov 23, 2012 at 3:26 PM, Richard Purdie <[email protected]> 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: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
