On Sat, 2007-03-10 at 12:36 +0100, Henryk Plötz wrote: > Ok, I see the source of confusion here. I was not implying to swap PR > and PV but instead extending it. From my abstract standpoint > + package version (1.2.0+svnnow), > + recipe version (r2), and > + source version (either in the form of the current date/time or as a > list of svn 'Last Changed Ref', git revision etc.) > are three different things with their importance in the listed order.
I disagree about the order. In my opinion, source version is part of the package version. > > Looking at the above problem, you would just have to ensure the order > > of the identifiers was properly controlled in PV. As long as the new > > SCM was at the end of the version, there shouldn't be a problem. > > Current code can't ensure a specified ordering (all URLs are at least > grouped by fetcher) and anyways this wouldn't solve the problem for all > possible cases. You can control the order in PV, the examples I gave explicitly showed how to do so. > (Another example: One of the subversion repositories I'm > using recently broke down and we had to setup a new one on another host, > where the revision numbers started at zero again. This would mean a new > recipe version because of a change of the URL-list, but an 'old' source > version.) There is one final variable that's been missing from these discussions which is package epoch (PE). This is supported by the underlying tools but not currently by bitbake itself. I mention it here as a change in sever like this might be a case where PE would change. There are patches around to add package epoch support around, waiting integration. > Let me try another abstract discussion. The way I see it, there are > three distinct issues: > (I) Determine when to recompile (and which recipe to use) > (II) What name to use for the tarball > (III) What name and version to use for the generated package (and > thereby implicitly: which package to use for the staging > environment) > > (II) is easy (basically use the url and fetcher specific metadata (svn: > Last Changed Rev, git: object name of the corresponding ref, cvs: > date/time of last change)) Agreed. > (I) is conceptionally easy: use the recipe with the highest PV-PR > (possibly constrained by the dependency that requested this build; note > that, as per my above assumptions, PV doesn't contain the source > version) and rebuild it when the fetcher specific metadata has changed. > I haven't yet looked into the necessary changes needed to implement > that behaviour. It all depends how you plan to integrate the source version. To me this has to be part of PV (not least because of our established version policy). > Note that the solutions to (I) and (II) don't imply any specific > ordering on the fetcher specific metadata, as long as it can be tested > for (in-)equality. Agreed. However I believe we might as use the same information for (I) and (III). > For (III) I'm not sure yet. Having a build date/time would be > acceptable, since it can be assumed that any project's buildhost > infrastructure is using synchronized clocks and any individual > developer's clocks would likely not be off by more than a few minutes. > A running build number would be acceptable too. However, both are worth > less than the recipe version which apparently ipkg can not express. I > can't think of a proper solution to this. (Well I can, but you would > run away screaming: Interleave PR and build number and put the result > in PR.) I'm basically suggesting a build number based on when the sources last changed is injected into PV, at least in the git case. In other SCM cases, there are nicer numbers we can inject. > > PV-PR is what it used to determine if the package should be rebuilt. > > At the moment, you could just set SRCDATE to the date of last change > > and it will then rebuild or not as appropriate. > > Hmm, that could be a possible solution when ignoring my inherent urge > to have source version worth less than recipe version. I think the > solution outlined by me above would be more correct in a theoretical > sense. As I've said, I don't agree. I've made my argument for using PV, not PR and there probably little else I can add. Regards, Richard _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
