On Mon, Oct 06 2008, martin f krafft wrote:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [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
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,
I just want to ship my preferred form of modification in the
This might not work for X.
But no technique is a perfect fit for all packages.
Where there's a will, there's a relative.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
vcs-pkg-discuss mailing list