recreating historic packages

[Manoj Srivastava]

On Wed, Oct 01 2008, martin f krafft wrote:

> also sprach Manoj Srivastava <srivasta at acm.org> [2008.09.30.2344 +0200]:
>>         Hmm. In my case, the integration and build branches are the same
>>  (master, for me). It would be slightly awkward to put stuff into a
>>  ./debian/patches for me, since ./debian is a submodule, and thus a
>>  different project. What you put into your build (master) branch, I put
>>  into a submodule. I find it conceptually cleaner; ./debian has little
>>  to do with upstream, but is close to all other ./debian directories in
>>  my other packages.
>
> Do you know of anyone else using this approach?

        No. But I do think it is a logical approach, and if we are
 trying for a common solution, we should cater to as many approaches as
 we can -- or, at least, not build into opur tools and standards
 limitations that prevent work-flows. This kind of decision ought not to
 be based on my lack of acquaintances. 

> I completely understand what you are saying, and I see the point.
> However, from the perspective of a whole distro, or even multiple
> distros working together, this only makes sense if everyone shares
> the same common base for ./debian. Else, packages get tied to their
> maintainers and even less cooperation will be possible.

        Why is having ./debian as a submodule tying packages to
 maintainers?

        You can put distro specific packaging information either in a
 separate project, and use a submodule, or graft it on to the upstream
 code in a branch (even if packaging code has little, if anything, to
 with upstream code). Both options are viable. Indeed, the former is
 more logical -- dismissing that approach since no one *you* know uses
 it bodes ill for any cross distribution undertaking.

> If we come to accept this, then I can't help but note that debhelper
> and cdbs already fill this niche.

        Why are you so hung up on the contents of ./debian? Heck, I
 could use cdbs and still put ./debian into a submodule.

        What difference does the build system make? Is it not a red
 herring?

> Fortunately, I don't think the discussion is about whether your
> submodules-based method makes sense or not, but about how we can
> harness the power of VCS for packaging.

        The power of the VCS is indeed what makes submodule
 possible. Can you get your head out of the sand wrt submodules? People
 can use submodules to pull together a package. Upstream may well use
 submodules as well. Just putting fingers in your ears and chanting
 na-nanana-na does not make the issue go away -- and your proposed
 solutions will all be a forgotten, unusable niche approach that falls
 by the way side.

> topgit is a pretty damn good contender so far, I think, as it allows
> the creation of a patch series as well as the merging of all
> feature branches into a monolithic diff. So we don't even have to
> discuss whether we should be creating patch series or not.

        If you say so. I am looking forward to the tg tag enhancements.

        manoj
-- 
"Don't talk to me about disclaimers!  I invented disclaimers!" The
Censored Hacker
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C