martin f krafft <madduck@xxxxxxxxxxx> writes:
> Thanks, Linus, for your time in answering my questions. I have some
> more comments and questions in reply. I hope I am coherent enough,
> this subject matter doesn't exactly flow off my tongue with ease
> yet...
>
> also sprach Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> [2007.07.10.0435 +0200]:
>> I really _think_ that what you want is to just use separate
>> branches, if I understand correctly. That makes it really easy to
>> just have both lines of development (both the "trunk" and your
>> "debian" one) in one git repository.
>
> It does mean, however, that I duplicate the upstream into my repo,
> and thus into the published repo at git.debian.org, because I cannot
> just publish a single branch ('debian') in such a way that people
> could clone it and still be able to build the package against
> upstream (which they'd have to obtain for themselves), right?
I've seen two kinds of debianized source tree. One kind has
changes already applied to the pristine source outside debian/
subdirectory, and debian/rules does the debian specific
customized build, install and packaging. The other kind does
not have _any_ change to the pristine except it has debian/
subdirectory and the first thing debian/rules does is to apply
patches to pristine from patch files kept in debian/
subdirectory. The answer largely depends on which arrangement
you have in mind for your package.
For the former kind, It is unavoidable for people to get your
(slightly modified) upstream source from you --- there is
nowhere else that stores what you changed. Extracting the
vanilla pristine and debian/ separately would not cut it. For
such an arrangement, "upstream" (or "pristine") branch would
contain everything you get from your upstream tarball (or SVN)
without any of Debianization changes (you can still have generic
"fixes and enhancements" of your own there to be fed upstream).
Your "master" (you could call it "debianization") branch will
fork off of that branch, and the first commit on that branch
would add debian/ subdirectory. All the debianization
modification to the upstream, if needed, also go to this branch.
Your users will clone and pull from your "master" and do
"fakeroot debian/rules binary" or whatever, and all is good.
For the latter, since the changes from upstream is isolated to
your additional debian/ subdirectory, you could arrange your
repository like this, even without using the subproject support:
.git/
.gitignore (perhaps untracked)
Makefile (upstream)
foo.c (upstream)
...
debian/.git
debian/rules (yours)
debian/control (yours)
...
Then, have the top-level .git/ repository control pristine
upstream sources from SVN (you may want to add .gitignore to
ignore debian/ subdirectory). In debian/, you create another
independent repository, and maintain _ONLY_ debianization. You
could even publish only that repository to your users without
publishing the upstream sources, if they know which version of
upstream source to use.
I tend to prefer the former, from the end user's point of view.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
