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? > If I thought a serialized patch series had sufficient benefits, I > would do the work. It has no conflicts. > 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? -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems http://www.vcnet.com/bms/
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss