On Tue, 2014-12-16 at 15:57 +0200, Markus Lehtonen wrote: > On Tue, 2014-12-16 at 11:53 +0100, Patrick Ohly wrote: > > Regarding the content of the per-package repos: I vote for storing the > > bb meta data in "meta-tizen" and only support it there. It feels cleaner > > than mixing it with .spec meta data and simplifies change tracking, > > because "git log meta-tizen" will not include the automatically > > updated .spec files. > > I'm probably inclined to this model as well. The downside is that the > additional packaging files are in two places but this should not be a > problem after the automatic generation of rpm metadata is turned on.
You remember that both Dominig and I argued that there should not be any project where rpm and bb meta data gets maintained manually at the same time. Agreed? So we'll never have to keep these extra packaging files updated manually in more than one place, except while testing the new tools. > > The big unsolved problem is indeed referring to the source code. > > A .bbappend file must not only add a reference to the Tizen git tree, it > > must also remove the one from the underlying .bb file. What that is > > depends on the .bb file and can change over time. > > I don't see why it should necessarily need to do this. One possible > source of problems in this (if the reference in .bb is not removed) is > that the OBS build and BitBake build might use different source code as > OBS build would use tarball created from Tizen Git whereas BitBake build > would fetch the real upstream tarball. Once we have bb meta data, OBS is told what to build by the meta translator, which will use the original SRC_URI and put the archive that it finds there into OBS. So both OBS and BitBake would ignore the source in the Tizen git tree. Actually, that would work. Was that your plan? I thought we still had the requirement to host all source code used for Tizen in the git trees, not just for gbs, but also because it removes the dependency on other download servers without having to introduce mirrors. Personally I'm fine with dropping that requirement. But then we need to think about publishing downloaded source code as part of automated Tizen builds based on Yocto. > That is, the SRC_URI would point to the real upstream tarball but there > would be need for some other reference which would point to the > (per-pkg) Git repository where the recipe itself is maintained in. Just make up something, for example SRC_URI_TIZEN or (as additional variable meta data) SRC_URI[tizen]. > > The per-package .bbappend (or .bb) can refer to the full git tree with > > the right branch and tag. > > > > For example, openssh_%.bbapped could look like this: > > > > SRC_URI_remove = > > "ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-6.6p1.tar.gz"; > > SRC_URI_prepend = > > "git://review.tizen.org/gerrit/platform/upstream/openssh;branch=upstream;protocol=ssh;rev=upstream" > > > > Some caveats: > > * The git fetcher is told to use ssh, so each developer has to > > configure that to work with review.tizen.org. Using anonymous > > HTTPS is not an option because review.tizen.org then asks for > > username/password via HTTP. > > * rev in the merged repositories needs to be replaced with a git > > commit hash. Using a tag or branch name implies that bitbake > > needs to access the network each time it starts, to determine > > what the actual source code is. That would be slow. I suggest to > > keep the string above as-is in the individual trees and only > > replace it when accepting a submission. > > * "gbp build-bb" is even more complicated. It should not reference > > review.tizen.org because that would imply fetching the git tree > > again. Perhaps remove the protocol and replace the URL with the > > local path? > > In this particular case I would not replace anything. Just use the real > upstream tarball. Got it. > GBS could be enhanced to start supporting these remote tarballs as well. > At that point it would be possible to avoid having upstream sources in > the Tizen Git at all. BitBake has fairly capable fetching code, so for full coverage GBS would have to be enhanced considerable (check out from git, subversion, download via http, https, rsync, etc.). I'm not sure whether that's worthwhile. OTOH, it would indeed be nice to get rid of the need to import upstream source code. > However, one problematic case might be the underlying .bb files that > refer to upstream Git. E.g. mesa: > SRCREV = "c7b9a2e38a3e471562b50dab8be65db8ac6819f8" > SRC_URI = "git://anongit.freedesktop.org/git/mesa/mesa;branch=10.4" > > We would need to have that same SRCREV in Tizen Git or then do something > like above (replace original SRC_URI and SRCREV with Tizen-specific > ones). Problematic for gbs or also for gbp? The translation to .spec doesn't care. > > Regarding test cases: you can find some .bbappend files for existing > > packages in meta-tizen, for example > > > > https://review.tizen.org/gerrit/gitweb?p=scm/bb/meta-tizen.git;a=blob;f=meta-tizen-adaptation/meta/recipes-multimedia/alsa/alsa-utils_%25.bbappend;h=a5db1d7a9c263d5dd7fef5d30338c7b7503818f1;hb=refs/heads/tizen > > > > alsa-utils.bb has some patches. So that covers a not too trivial > > "non-native in orphaned packaging mode" example. > > > > Another one with patches in the .bbappend is > > https://review.tizen.org/gerrit/gitweb?p=scm/bb/meta-tizen.git;a=blob;f=meta-tizen-adaptation/meta/recipes-support/sqlite/sqlite3_%25.bbappend;h=adedafc8629be1661c6964bb200b876cdba23edd;hb=refs/heads/tizen > > > > There's no readily available example for "non-native + joint packaging", > > but it wouldn't be hard to turn one of those into that. > > > > Native meta data currently only exists from the spec2yocto tool, for > > example: > > > > https://review.tizen.org/gerrit/gitweb?p=scm/bb/meta-tizen.git;a=tree;f=meta-tizen-common-base/recipes-support/adns;h=2c930eff76f01a4cea24d1dcaffa75b8c6c23dfd;hb=refs/heads/tizen > > Thanks for the pointers. I will test with these. Note the common pitfall with these URLs: replace gerrit/gitweb with git if you are not logged into gerrit. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
