Re: [PATCH] Map git objects to buildchroot

[Christian Storm <christian.storm@siemens.com>]

> [...]
> BTW: we always have option to clone git repository to workspace by 
> running in ${WORKDIR}/git:
> 
> $ git repack -a
> 
> in do_build() task. With this, no extra mount/umount logic is needed.

Yes, right, providing a (proper) git checkout in the working directory
solves the problem, as a mount --bind does. For a proper checkout,
you'll have to have the (entire) history/tags available, i.e., not a
shallow clone. For large repositories, this may take some time which a
mount --bind does not consume. On the pro side, using a (proper)
checkout, there's no way to mess with the repository from within the
buildroot, i.e., building from the same source twice - for whatever
reason - uses the exact same revision as base: Changes made to the
repository in one don't affect the other.
That said, I'm fine with both solutions.

So, would you go ahead and post a patch, Alex?


> We could consider this behavior for source 3.0 packages only by using 
> some flag in recipe.

Well, no. This way you're entangling Debian packaging internals to the
recipe. I would opt against this. Most probably you'll want to do git
operations even if you don't use source 3.0 (git) packages, e.g.,
getting the latest git tag or whatever. So, I'd opt for doing it for
every source git package, unconditionally.



Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Otto-Hahn-Ring 6, 81739 M�nchen, Germany