the goal of vcs-pkg

[Manoj Srivastava]

On Mon, Oct 06 2008, martin f krafft wrote:

> also sprach Manoj Srivastava <srivasta at acm.org> [2008.10.02.2006 +0200]:
>>         Now suppose you have your _own_ heirarchy of debian
>>  directories.  You can just change the submodule location, which is only
>>  referred to in the build branch, and continue with ever other feature
>>  branch inherited straight from me.
>
> Or, by extension, someone could just swap ./debian for ./fedora
> (yes, I know that directory does not exist and that it would be
> a .spec file, but just assume for a minute) and the package would be
> built for Fedora.

> How are you going to deal with the fact that a given software
> expects, e.g /usr/libexec/topgit/tg-export to exist, which I've
> moved to /usr/share/topgit/tg-export on Debian? Should debian/rules
> move the file into place after install, or should I patch the
> Makefile? What if the path is hardcoded in places?

        Traditionally, one sets up a dist/configure or automake rule
 that figures out where the lib is, and the software uses indirection to
 determine the TG_LIBEXEX_DIRPATH or something.


>>         If I thought a serialized patch series had sufficient benefits, I
>>  would do the work.
>
> It has no conflicts.

        This is only a nominal benefit. If I ship the integration branch
 as the diff.gz, you have  no conflicts to use the all the features
 built.

        Now, If I want to try just topic F, it is easier with pure topic
 patches. Trying just feactures E and H is also easier with just the
 pure topic patches, though perhaps with some work.

       I am looking at the common cases here. I posit the most common
 case is to:
  a) Want all the features (use the diff.gz integration branch)
  b) Try a single feature (use orig.tar.gz and the pure feature patch)

        Combinations of a subset of the patches are still relatively
 easy, at he expense of perhaps needing some work.

>>         I think providing the integration branch, and each pure feature
>>  branch via patches, is strictly superior to just providing serialized
>>  (impure) feature branches and generating the integration or build
>>  branch on the fly.
>
> It also introduces 100% redundancy into the source package, no?

        *Shrug*.  To get to this developers preferred mode of working,
 there is redundancy in the feature branch + integration branch mode,
 yes.

        I just want to ship my preferred form of modification in the
 source package.

        This might not work for X.

        But no technique is a perfect fit for all packages.

        manoj
-- 
Where there's a will, there's a relative.
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C