may be something like 3.0 (git-annex) source format?

[Yaroslav Halchenko]

> Funny timing, I have been pondering exactly this question for the last few days.
;-)

> > just a blunt idea -- what if 3.0 (git) format (with which I haven't
> > played before either)
> Afaik, 3.0 (git) does not really exist. At least not inasmuch as you
> can tell it "use these commits". We are still stuck with 3.0 (quilt),
> for now.

yes and no... so I have even tried and even accomplished a mission with
1) setup you have described for a little data package:

http://git.debian.org/?p=pkg-exppsy/sri24.git

I was surprised to find that 3.0 (git) somewhat worked (git-buildpackage I used
wasn't aware of it but raw dpkg commands worked just fine) -- I got .git
and .dsc files.

There were inconsistently funny hickups from git-annex+git while trying
to build it in a clean chroot (cowbuilder), which I thought to distill
more and report back but didn't have time... so here they are raw:

 - first it failed with git requiring me to specify name/email
 - upon entry via hook it build binary just fine with debian/rules binary
 - when I removed extracted source directory and  dpkg-source -x it
   again, git annex started whining that he wasn't initialized there and even
   after I did git annex init, and it did show knowing about whatever number of
   urls in web backend it quietly refused to fetch them

> As joeyh pointed out, you need the data in the orig if it's to be
> included in the package.

yeap -- deserted island test would fail in as it is now setup.  Also suggested
reliance on binary packages would not probably work due to chicken/egg
problem, not to mention that some times data needs to be reprocessed
(converted) before placed into binary package. most of the time transformations
are reversible but still -- it would be unnecessary burden imho.

But for non-official use I think this solution is quite nice...  I am also
thinking about adding debian/control field pointing to alternative (to web
urls) local  git annex repository containing the load, so that package could be
built without fetching data from the web during build.

May be it would be possible to elaborate later on 3.0 (annex) format where
additional .annex would be provided to accompany both .dsc (source) and .deb
(binary) packages with the actual load and 2) approach used for the actual
installation.  Although then not sure how much it would be of benefit to
use annex instead of just coming up with a solution where .data.tar.gz could be
shared by both source/binary packages.

> That being said, there are three possible approaches:

> 1) `git-annex get` files during package creation; build-dep git-annex
>     pro: Packaging repo is slim by default
>     con: package & orig are large, install(1) copies symlinks verbatim

> 2) `git-annex get` during postinstall; dep git-annex
>     pro: package & orig are small
>     con: installation takes ages, can not be interrupted, etc


> 3) `git-annex get` after installation; dep git-annex
>     pro: package & orig are small, easy installation
>     con: user needs to do manual work after installation, most likely
> needs root (again)

> Richard
-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic