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

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

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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: