Moin,
Am Fri, 09 Mar 2007 09:46:29 +0000 schrieb Richard Purdie:
> PR is defined to be worth less that PV and this assumption is
> hardcoded into the underlying tools and into the developers minds.
> When you add a new version you zero PR.
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.
In an ideal world we could just use this three-tuple, but after reading
what you've written I agree that we can't just change this. See below.
> 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. (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.)
> I think we need to expose more data from the fetchers such as a
> REVISION tag for each SCM referenced in SRC_URI so you could do
> something like:
>
> SRC_URI = "\
> cvs://someurl;refname=scm1 \
> svn://someurl;refname=scm2"
>
> PV = "x.y.z+cvs${SRCREVISION_scm1}+svn{SRCREVISION_scm2}"
>
> Setting such a PV doesn't seem like too much of a pain for these
> relatively rare corner case packages.
Agreed under the assumption that source version was worth more than
recipe revision.
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))
(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.
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.
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.)
> This means changing the defined behaviour of things like ipkg, apt,
> dpkg and Debian packaging policy. This is not something many
> developers will accept and I'm not sure it would work either.
I see.
> 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.
--
Henryk Plötz
Grüße aus Berlin
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev
