[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-source's future and relation with VCS



Anthony Towns <aj@azure.humbug.org.au> writes:

> My point is precisely that it's *NOT* useful now.

> The other VCS systems are, because they *have* the VCS backend you need
> to manage and manipulate history/changesets/patches/etc. Wig&Pen isn't,
> because it doesn't have those tools.

No software is useful until it is implemented.  wig&pen is far from unique
in that regard.

The fundamental point of disagreement that we seem to have is that you
think that implementing conversion to and from wig&pen is hard, whereas I
think I disagree (it looks pretty trivial to me for the large number of
Debian packages that currently use dbs, quilt, dpatch, or simple-patchsys,
and not horribly difficult for straight Git and bzr repositories that use
branches).  Since I don't we're going to resolve that argument until
someone tries, there doesn't seem to be much point in arguing about it, I
guess.

This, however:

> I haven't used quilt, but I don't believe there's anything that would
> make it difficult to port Joey's git plugin to being a quilt plugin.

sounds like convergence towards exactly what Raphael was talking about,
no?  So maybe this is a good way forward.  A quilt plugin to that
framework that also has hooks to unpack multiple tarballs ends up looking
remarkably like wig&pen, and then the argument about whether we can or
should convert to and from that format can be decoupled from the issues
around the availability of the format itself.

In fact, that would largely reduce all issues of conversion to a simple
technical implementation detail that people could work on or not as it
felt useful, which seems like exactly where we'd want to be.

> Uh, you're discussing something other than Wig&Pen then...

Er, yes, there was a whole debian-devel discussion about how wig&pen
should change to be a useful representation of existing practice, and that
was what Raphael's original message was based on.  If you weren't aware of
that, that might go a long way towards why we're talking at
cross-purposes.

Anyway, http://wiki.debian.org/GitSrc sums up the concern I have about a
VCS-driven package format:

| Q: But doesn't this mean that people have to learn git to contribute to
| or NMU my package?
| 
| A: Yes, contributors or NMUers will need to know some basic git commands
| like "git commit -a", since any change they make needs to be checked in
| before the package is built.
| 
| Q: Might this not be the start of a slippery slope? I don't mind
| learning git, but what if we get a dozen other revision control systems
| used in source packages?
| 
| A: It will be up to the dpkg developers to keep things sane. (Obligatory
| comment about sanity of dpkg developers elided. ;-) On the other hand,
| having a real revision control system available in the source package
| format leaves need for dbs and all its ilk. You have to learn them too,
| before contributing to a package that uses them. So in the end adding
| git to the source format might make things simpler and more
| standardised.

The goal is to fix the underlying problem that right now you have to know
the tools of the package maintainer in order to maintain the package.
Both a multitude of VCS-driven package formats and wig&pen are a huge
improvement over the current state.  Even if we have a VCS package format
for every VCS known to man, it's already a huge improvement over the
current state because you can at least hack on the package in basic ways
without learning the VCS (provided that dpkg-source can do the basic
commit for you), or learning only the most minimal commands.

I see some potential in wig&pen for something even better than that in the
current environment of no VCS agreement, namely a common interchange
format that lets people use the VCS of their choice and generate packages
that anyone else can similarly use the VCS of their choice on to do
moderately complex (but not the most difficult) operations on.

If tailor works now as a many-to-many conversion tool, that would address
my concern even better.  The point of wig&pen would be to be a conversion
hub that everything could speak; if that's not easier to implement than
direct conversion, then obviously there's no point in having it.

It's certainly trivial to convert a package that uses quilt to the Git
format.  You just import the upstream tarball on an upstream branch, clone
it to master, create a feature branch for every patch, merge them all into
master in the order specified by the series file, create a debian branch,
add the debian directory on that branch, and merge that branch into
master).  In fact, it's basically this script:

    git init
    git checkout -b upstream
    dpkg-source -x ../<dsc> .
    rm -rf debian
    git add .
    git commit
    git checkout master
    git merge upstream
    git checkout -b debian
    dpkg-source -x ../<dsc> .
    mv debian/patches ../patches
    git add debian
    git commit
    git checkout master
    for patch in `cat ../patches/series` ; do
        git checkout -b "feature/$patch"
        patch -p1 < ../patches/"$patch"
        git commit
        git checkout master
        git merge "feature/$patch"
    done
    git checkout master
    git merge feature/`tail -1 ../patches/series`
    git merge debian

In practice, it would be nice to add a bit more intelligence to remove the
false ordering in the series file by checking whether the patch would
apply independently of its predecessors and, if so, doing some git rebases
in there on the feature branches.  But that gives the basic idea.

> So great, I've nothing against quilt. But quilt isn't Wig&Pen, and
> forcing all DDs to switch from git, darcs, bzr, or whatever to quilt
> isn't ok, just because you like it.

I think we all agree that the whole point of the exercise is to minimize
the degree to which anyone is forced to use any specific tool other than
dpkg-source and dpkg-buildpackage to manipulate Debian packages.

> I'd love to see both those things fixed so we can upload packages in any
> format after lenny's released; but I'd hate to see git/bzr format get
> blocked on Wig&Pen, and then miss out on lenny because Wig&Pen just
> isn't up to snuff and have us end up with neither for another cycle.

On this we agree -- I see no reason why adopting the VCS format should be
in any way dependent on wig&pen.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: