recreating historic packages
srivasta at acm.org
Wed Oct 1 15:20:50 UTC 2008
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
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
> 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.
"Don't talk to me about disclaimers! I invented disclaimers!" The
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
More information about the vcs-pkg-discuss