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

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

On Wed, 13 Feb 2008, Anthony Towns wrote:
> On Mon, Feb 11, 2008 at 02:46:33PM +0100, Raphael Hertzog wrote:
> > 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]
> I don't think it's feasible to require that. It's a great goal, but
> we're not there, and may not be there by lenny; and having a better
> source format for lenny+1 is more important than that goal.

It is easily feasible. However if we do it, we'll have bigger source
packages and you can't allow upload of those to ftp-masters. I still
believe it to be a worthy goal... at least to match those requirement
(taken in one of your messages):
        - doesn't requires lots of dependencies on other code
	- doesn't become obsolete and block you from unpacking old
	  source packages

We can extract without VCS and have a look at stuff. Even if the DVCS
doesn't handle a 10-year old repository, we still have the content even if
we don't have access to the history.

It might be worth discussing on the upstream git mailing list to see how
we can save maximum of space while keeping a checkout.

> > - it will take several years until we can standardize on VCS-based source
> I don't think we have a VCS-equilvaent source package format that's worth
> considering standardising on: .tgz and .orig/.diff aren't powerful enough,
> git and bzr are too system specific, and wig&pen is too unimplemented.

I already stated my intent to work on a wig&pen based format. 

(We only have two months from now (until beginning of April) to add new
features to dpkg/dpkg-dev)

I don't plan to block anything concerning VCS-based formats, however I do
believe that the mixed approach I outlined fit better the Debian community
as a whole given that it can also be usefully combined with VCS. 

It simply gives two workflows:
- the maintainer workflow "debcheckout, hack, debcommit, debuild"
- the NMUer workflow "apt-get source, hack, debuild"

> So while I'm not exactly disagreeing with either premise, I don't think
> it makes sense to consider them atm. If they do eventually work out, to
> the point that dpkg will auto convert VCS-managed repos to tar+patches
> and back again in useful and convenient ways, then we can start REJECTing
> .git/.bzr/.hg/whatever uploads that we will have been accepting in the
> meantime, and expect maintainers to do that.

Fine. I just want constructive comments so that my work brings us closer
to that goal. :-)

Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :

Reply to: