also sprach Jan Hauke Rahm <> [2009.03.24.1153 +0100]:
> After some thinking I started implementing a Repository class as an
> intelligent wrapper around SVN::Client (OOP in perl is weird by the
> way).

… don't get me started. :)

> Writing a new VCS based packaging helper does not make any sense
> without considering current efforts in abstracting things. And
> basically that's why I'm here now: I don't want to write a tool
> that's about to be replaced anyways any time soon.
> So, how far have you come by now? Is it worth putting energy in
> vcs-pkg and is there any chance that we get a working replacement
> for svn-bp out of it before squeeze freezes? Otherwise I would
> have to concentrate more on svn-bp since it really needs a new
> version (it won't work with squeeze's archive because of Format
> 3.0 (quilt)!).

This is a hard question to answer. By comparison with svn-bp,
vcs-pkg has not really gotten anywhere yet: we do not have any
output in this sense. To date, vcs-pkg has mainly been discussions
and a commonly shared goal to unify package maintenance across
distributions and version control systems.

One nice output of this project would be something akin to svn-bp,
a tool that you run from a checkout, which does everything needed
for the distribution you asked it to. Part of the charm of this
approach is to be able to build packages for multiple distributions,
and encourage and facilitate exchange between distros.

I am very much of a bottom-up person, but I am unsure it's the right
approach in this situation. Look at svn-bp: it grew such that many
projects only track the ./debian directory; for many, this is now
a major showstopper in trying to migrate to distributed version
control. At the same time, svn-bp does not make use of branches,
probably because svn doesn't really know what a merge operation is,
and advocates tracking patches in version control. If you've ever
tried to debug one of those, you'll join me: Ugh!

I don't know what the vcs-pkg tool will look like or what it'll do,
because I only really know a few workflows used in Debian. From
brainstorming sessions at conferences, I know that other
distributions are essentially doing the same (after all, we all just
track changes to the upstream source to make the package work with
our distro), but I don't really know how the others do it.

There is also the question of whether a single vcs-pkg tool has any
future. It's going to be hard to design it, and we will all have to
work together, which is unlikely to happen within a short timeframe,
giving the limited time we all have.

Trying to standardise a single tool is kind of a wasted effort. But
trying to standardise interfaces is not.

Maybe the best way forward would be to abstract across
SVN/Git/Bzr/Hg for the simple operations needed for package
maintenance, and then to implement a tool like svn-bp for Debian,
except that it uses the abstraction layer and can thus work with any
repo type. Furthermore, maybe the tool could support different
workflows, e.g. support tracking patches in debian/patches alongside
TopGit-like functionality to track those features in proper
branches. This would allow people to use the tool for their existing
packages, and slowly move to other maintenance methods, without
having to migrate all the existing stuff.

Once such a tool works for Debian, maybe other distros will take
a look and see how it can be tweaked to their use-case. After all,
except for 'debian/patches' and the 'dpkg-buildpackage' command it
eventually calls, there's nothing inherently Debian-specific in any
of this. Maybe it'll be trivial for e.g. Fedora to use the tool
after exchanging those components with their own versions. And then
we could learn from each other and improve the tool.

I've probably nicely danced around your actual question, but maybe
what I've written can help a bit. If instead of working on svn-bp,
you'd be interested in helping to make the above happen, then
I think you should. I'll gladly assist wherever I can.

 .''`.   martin f. krafft <madd...@d.o>      Related projects:
: :'  :  proud Debian developer     
`. `'`
  `-  Debian - when you have better things to do than fixing systems
the english take english for granted.
but if we explore its paradoxes,
we find that quicksand can work slowly.

Attachment: digital_signature_gpg.asc
Description: Digital signature (see

vcs-pkg-discuss mailing list

Reply via email to