On Tue, Feb 12, 2008 at 12:51:12AM -0800, Russ Allbery wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:
> > My point is precisely that it's *NOT* useful now.
> No software is useful until it is implemented. wig&pen is far from unique
> in that regard.
Right, but the git/bzr stuff _is_ implemented...
Skipping to the end:
> > 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.
Good -- that's the only thing I'm saying here.
AFAICS where we're at is:
- we've got a new plugin architecture for supporting source
package formats, which will at least cover v3 source formats for
git/bzr tarballs. It needs some minor finalisation (behaviour
when there are uncommitted changes, Source-Depends), but
that's it.
- the dpkg-source code might be cleaned up, to have a Dpkg::Source
API (Raphael) and to use the plugin architecture for the v1
and v2 source formats too (Frank).
- Raphael's looking at enhancing the wig&pen format (eg, adding
a file explicitly listing patches to apply), and making
dpkg-source able to generate a wig&pen format package; Russ may
be looking at automating the process of generating wig&pen format
packages for packages maintained using quilt
- none of the new formats are accepted by the archive; to become
accepted, any particular format needs:
- a demo of the format working effectively, so we can see
what it takes to maintain a package with it, and what the
actual output is, and to use as a test case
- the format to be supported in dpkg mainline
- the format to be unpackable by users running stable
(ideally with apt-get and dpkg-source -x; but possibly
by hand, or with a backported package)
as well as an appropriate patch to dak.
> 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?
That's not what I got from:
] - dpkg-dev (or dpkg-dev-vcs) provides VCS-specific scripts in
] /usr/share/dpkg-dev/ that can be used to generate a wig&pen source
] package from a VCS repository
and more particularly:
] However I'm also convinced that:
] - a source package should be unpackable without a VCS. This means that
] somehow it should contain a checkout that can be extracted with basic
] tools. [1]
] - it will take several years until we can standardize on VCS-based source
] package whereas the switch to wig&pen can be quick. In the mean time, a
] nice intermediary solution is to generate the wig&pen source package
] from the VCS.
I don't think standardising on a VCS is an option, be it git or quilt or
anything else; and I do think standardising on a format, at least with
the technology we have now or are likely to have soon will require that.
We've got a bunch of requirements:
- dpkg-source -x can unpack to the bare code
- can manage a large number of Debian specific patches
- can easily merge with upstream changes
- can easily merge with downstream changes (Ubuntu, local admin, etc)
- doesn't require any learning on behalf of maintainers
- doesn't require any learning on behalf of NMUers
- doesn't require any learning on behalf of admins/users
- doesn't requires lots of dependencies on other code
- doesn't become obsolete and block you from unpacking old source
packages
Standardising on a single source format isn't that important, and afaics
avoiding making people install git-core, bzr, darcs, quilt, etc isn't
either -- getting all the above right is though.
> 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.
So way back in the day, I did try writing a conversion tool from darcs to
wig&pen and back -- the problems I had were that it was kludgy to manage
because of the way the patches weren't separated from everything else (eg,
there's nothing stopping a Wig&Pen patch from patching an earlier/later
Wig&Pen patch) and it was really slow to actually replay through the
darcs history to generate the patches.
> > 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.
Well, changing the Wig&Pen format has the drawback that dpkg in etch can't
unpack it, which puts it even more at the same level as the git format.
> 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, [...]
There's three ways to avoid that:
- have dpkg auto-commit the change, which is what Frank's proposing
as the default behaviour
- have dpkg give an error that tells you exactly what to type to commit
the change
- use a tool like debcommit that knows how to commit changes for all
supported VCSes
Wig&Pen has the same issue; it's just not noticable atm because there's
no way to create a source package in the first place, even if you haven't
changed anything...
> | 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?
Yes, it is a slipper slope; but any of the above answers for committing
changes lets you avoid learning new VCSes just to make a one-shot change
to a package. If you want to do ongoing merges against new versions,
you need to learn the VCS of the package, though.
> 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.
I don't think that's avoidable -- the goal is to avoid learning in order
to NMU the package and poke at its source. If you want to co-maintain
or take over a package, you'll have to learn something.
> 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.
Well, it's easier than that even -- if you can do the initial unpack,
you can hack on it and then just create a native .tar.gz. No VCS learning
needed at all, even if dpkg can't run "git commit" for you.
> 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.
Yes, that was always the intent. My money's on it not happening, though.
> If tailor works now as a many-to-many conversion tool, that would address
> my concern even better.
Uh, you don't know about tailor? http://progetti.arstecnica.it/tailor
> 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.
The big point of having it is it's human readable -- so in five years
when we want to grunge through lenny+1's sources, you can do so by hand.
> > 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.
Yeah, it's not just that though (otherwise orig+diff would be fine);
it's to make it easy for maintainers to maintain complicated packages
at the same time, along with all the little bits I mentioned above,
and probably some I forgot.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature