Message ID | 1446915053-13783-3-git-send-email-bernd.kuhls@t-online.de |
---|---|
State | Rejected |
Headers | show |
Hello, On Sat, 7 Nov 2015 17:50:52 +0100, Bernd Kuhls wrote: > This package only provides a git submodule for the vsxu package. > > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> I don't really like the interaction between this package and the vsxu package, but I don't really have a better proposal to be honest. Yann, Peter, Arnout, do you have some suggestions on how to handle such git submodule cases? Thanks, Thomas
Thomas, All, On 2015-12-19 15:00 +0100, Thomas Petazzoni spake thusly: > On Sat, 7 Nov 2015 17:50:52 +0100, Bernd Kuhls wrote: > > This package only provides a git submodule for the vsxu package. > > > > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> > > I don't really like the interaction between this package and the vsxu > package, but I don't really have a better proposal to be honest. > > Yann, Peter, Arnout, do you have some suggestions on how to handle such > git submodule cases? I really don't know what to do with git-submodules. But in this precise case, I would: - dump the cal3d package - add a post-download hook (or an extra-download URL) to vsxu to also download cal3d - add a post-extract hook to vsxu to also extract cal3d in the correct location. Then, when/if cal3d is later used by other packages, we can revisit the situation. Otherwise, for proper git-submodule handling, we would have to do (roughly): git clone blabla pkg-version cd pkg-version git checkout pkg-version git submodule update --init --recursive find . -name .git -exec rm -rf {} + cd .. tar czf DL_DIR/pkg-version.tar.gz pkg-version/ This is not very complex, but is stil la significant change from our current git wrapper. And then, what about svn externals? About Hg subrepos? Does bzr also have such a thing? Note that I would not really mind doing such a change. But is it worth it, given that we currently have only one package that needs submodules? Or do we have others for which we had to "deal with it" in a crude way? Regards, Yann E. MORIN.
Yann, On Sat, 19 Dec 2015 15:25:09 +0100, Yann E. MORIN wrote: > But in this precise case, I would: > - dump the cal3d package > - add a post-download hook (or an extra-download URL) to vsxu to also > download cal3d A post-download hook wouldn't play well with "make source", "make legal-info" and all. We have to take this into account. But an EXTRA_DOWNLOADS should work fine. > - add a post-extract hook to vsxu to also extract cal3d in the correct > location. Could be a solution, I'll try this. > Otherwise, for proper git-submodule handling, we would have to do > (roughly): > > git clone blabla pkg-version > cd pkg-version > git checkout pkg-version > git submodule update --init --recursive > find . -name .git -exec rm -rf {} + > cd .. > tar czf DL_DIR/pkg-version.tar.gz pkg-version/ > > This is not very complex, but is stil la significant change from our > current git wrapper. > > And then, what about svn externals? About Hg subrepos? Does bzr also > have such a thing? > > Note that I would not really mind doing such a change. But is it worth > it, given that we currently have only one package that needs submodules? > Or do we have others for which we had to "deal with it" in a crude way? I don't want to go down this route for the moment, I'd prefer to see how many of these git submodule users we have. Thomas
On 19-12-15 15:00, Thomas Petazzoni wrote: > Hello, > > On Sat, 7 Nov 2015 17:50:52 +0100, Bernd Kuhls wrote: >> This package only provides a git submodule for the vsxu package. >> >> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> > > I don't really like the interaction between this package and the vsxu > package, but I don't really have a better proposal to be honest. > > Yann, Peter, Arnout, do you have some suggestions on how to handle such > git submodule cases? Good that Bernd put that reference to my mail of two years ago [1]. When I read that again I first thought that I would retract my statements from back then, but in fact it still makes sense. There are basically two ways that we can consider such packages. The first way is to say it is a bundled package, in other words we download and extract the submodule as part of the master. We have a precendent for this: perl-cross (though there it's a bit the other way round, the principle is the same). I described this approach as the first option for [1]. The second way is to say that it is a separate package and we basically unbundle it. Since the package itself doesn't support that, we have to do some hacks to make it work, just like any distro has to make hacks to unbundle stuff. The second way is hackish because: - we're instantiating the submodule in a different way than the package expects it (as a symlink rather as a subtree); - we're referring to the source of one package from another package. This last bit, however, is something we do all the time with LINUX_DIR, so maybe it's not that much of a hack after all. The second way tends to be a bit less verbose too, because we can use a lot of infrastructure that just doesn't exist to support the sub-package approach. But it's not as bad anymore as when I wrote [1], because now we can use _EXTRA_DOWNLOADS at least, so we just need to add a post-extract hook. So the difference is just 2-3 lines. I have a slight preference for the first approach, but I would be fine with the second approach (which Bernd chose here) as well. Though I do have a few comments on that, which I'll state in the patch itself. Regards, Arnout [1] http://lists.busybox.net/pipermail/buildroot/2013-March/069971.html
On 07-11-15 17:50, Bernd Kuhls wrote: > This package only provides a git submodule for the vsxu package. > > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> > --- > v2: no changes > > package/Config.in | 1 + > package/cal3d/Config.in | 6 ++++++ > package/cal3d/cal3d.mk | 10 ++++++++++ > 3 files changed, 17 insertions(+) > create mode 100644 package/cal3d/Config.in > create mode 100644 package/cal3d/cal3d.mk > > diff --git a/package/Config.in b/package/Config.in > index d278e64..eb601e8 100644 > --- a/package/Config.in > +++ b/package/Config.in > @@ -227,6 +227,7 @@ comment "Graphic applications" > source "package/rrdtool/Config.in" > > comment "Graphic libraries" > + source "package/cal3d/Config.in" > source "package/cegui06/Config.in" > source "package/directfb/Config.in" > source "package/directfb-examples/Config.in" > diff --git a/package/cal3d/Config.in b/package/cal3d/Config.in > new file mode 100644 > index 0000000..231d905 > --- /dev/null > +++ b/package/cal3d/Config.in > @@ -0,0 +1,6 @@ > +config BR2_PACKAGE_CAL3D > + help > + Cal3D is a skeletal based character animation library. > + This package provides a git submodule for the vsxu package. > + > + https://github.com/vovoid/cal3d If you take this approach (which, given Yann's and Thomas's feedback, you probably won't), then I don't think you should add a Config.in file. It makes no sense at all for the user to be able to select this package, because it doesn't install anything in staging or target so it cannot be used. Regards, Arnout > diff --git a/package/cal3d/cal3d.mk b/package/cal3d/cal3d.mk > new file mode 100644 > index 0000000..0a7813f > --- /dev/null > +++ b/package/cal3d/cal3d.mk > @@ -0,0 +1,10 @@ > +################################################################################ > +# > +# cal3d > +# > +################################################################################ > + > +CAL3D_VERSION = 0f640189eec913973c64db3bc1c1685554cb7202 > +CAL3D_SITE = $(call github,vovoid,cal3d,$(CAL3D_VERSION)) > + > +$(eval $(generic-package)) >
On 19-12-15 15:25, Yann E. MORIN wrote: > Thomas, All, > > On 2015-12-19 15:00 +0100, Thomas Petazzoni spake thusly: >> On Sat, 7 Nov 2015 17:50:52 +0100, Bernd Kuhls wrote: >>> This package only provides a git submodule for the vsxu package. >>> >>> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> >> >> I don't really like the interaction between this package and the vsxu >> package, but I don't really have a better proposal to be honest. >> >> Yann, Peter, Arnout, do you have some suggestions on how to handle such >> git submodule cases? [snip] > Otherwise, for proper git-submodule handling, we would have to do > (roughly): > > git clone blabla pkg-version > cd pkg-version > git checkout pkg-version > git submodule update --init --recursive > find . -name .git -exec rm -rf {} + > cd .. > tar czf DL_DIR/pkg-version.tar.gz pkg-version/ Err, anything wrong with just adding --recursive to the clone command? Or is that a recent addition? Oh, but git archive still wouldn't add it of course. But anyway, in this particular case we're using a github tarball download so it wouldn't help. Unless it would switch to git download instead. > > This is not very complex, but is stil la significant change from our > current git wrapper. > > And then, what about svn externals? About Hg subrepos? Does bzr also > have such a thing? > > Note that I would not really mind doing such a change. But is it worth > it, given that we currently have only one package that needs submodules? > Or do we have others for which we had to "deal with it" in a crude way? I'm pretty sure there aren't any other packages that need it. Regards, Arnout > > Regards, > Yann E. MORIN. >
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, > I really don't know what to do with git-submodules. > But in this precise case, I would: > - dump the cal3d package > - add a post-download hook (or an extra-download URL) to vsxu to also > download cal3d > - add a post-extract hook to vsxu to also extract cal3d in the correct > location. > Then, when/if cal3d is later used by other packages, we can revisit the > situation. Yes, I think that makes sense as well. > Otherwise, for proper git-submodule handling, we would have to do > (roughly): > git clone blabla pkg-version > cd pkg-version > git checkout pkg-version > git submodule update --init --recursive > find . -name .git -exec rm -rf {} + > cd .. > tar czf DL_DIR/pkg-version.tar.gz pkg-version/ > This is not very complex, but is stil la significant change from our > current git wrapper. Yes, I would prefer if we wouldn't have to do that. > And then, what about svn externals? About Hg subrepos? Does bzr also > have such a thing? For svn we create the tarball ourselves, so I believe externals should work. I'm not really familiar with hg, but I guess it behaves like git. > Note that I would not really mind doing such a change. But is it worth > it, given that we currently have only one package that needs submodules? > Or do we have others for which we had to "deal with it" in a crude way? I had a local package at work that originally used git submodules, and the gstreamer packages use a submodule for "common stuff", so we would have the issue if we ever moved to getting these from git. So I think there is a potential use case for it, but it is really quite a pity that they aren't handled natively by git archive. Perhaps we should bring it up with the git developers?
diff --git a/package/Config.in b/package/Config.in index d278e64..eb601e8 100644 --- a/package/Config.in +++ b/package/Config.in @@ -227,6 +227,7 @@ comment "Graphic applications" source "package/rrdtool/Config.in" comment "Graphic libraries" + source "package/cal3d/Config.in" source "package/cegui06/Config.in" source "package/directfb/Config.in" source "package/directfb-examples/Config.in" diff --git a/package/cal3d/Config.in b/package/cal3d/Config.in new file mode 100644 index 0000000..231d905 --- /dev/null +++ b/package/cal3d/Config.in @@ -0,0 +1,6 @@ +config BR2_PACKAGE_CAL3D + help + Cal3D is a skeletal based character animation library. + This package provides a git submodule for the vsxu package. + + https://github.com/vovoid/cal3d diff --git a/package/cal3d/cal3d.mk b/package/cal3d/cal3d.mk new file mode 100644 index 0000000..0a7813f --- /dev/null +++ b/package/cal3d/cal3d.mk @@ -0,0 +1,10 @@ +################################################################################ +# +# cal3d +# +################################################################################ + +CAL3D_VERSION = 0f640189eec913973c64db3bc1c1685554cb7202 +CAL3D_SITE = $(call github,vovoid,cal3d,$(CAL3D_VERSION)) + +$(eval $(generic-package))
This package only provides a git submodule for the vsxu package. Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> --- v2: no changes package/Config.in | 1 + package/cal3d/Config.in | 6 ++++++ package/cal3d/cal3d.mk | 10 ++++++++++ 3 files changed, 17 insertions(+) create mode 100644 package/cal3d/Config.in create mode 100644 package/cal3d/cal3d.mk