Re: 3.0 (git) "experimental"
Hi,
On Mon, 14 Apr 2008, Anthony Towns wrote:
> On Sat, Apr 12, 2008 at 10:04:03AM +0200, Raphael Hertzog wrote:
> > Well, I wrote the manual page, so it was my decision but I believe it's
> > backed up by my opinion and the one expressed by Guillem:
> > Instead I chose to mark them as experimental to show that we don't believe
> > that they are ready to be used in large-scale (like, say, on ftp-master).
>
> Uh, whether they're ready to use on ftp-master isn't up to just the dpkg
> team.
That's granted.
> And if that were the reason to mark them experimental, then Format:
> 2.0, Format: 3.0 (native), Format: 3.0 (quilt) and Format: 3.0 (custom)
> should all have been marked experimental too.
Well, I don't think those formats suffer from all the limitations that
have been expressed in the two mails that I quoted.
> The custom format in particular is unlikely to ever be accepted, it
> seems to me;
The custom format is not a format. You'll never see 3.0 (custom) in a .dsc
header. Consider this format as a a dsc writer for tools like
git-buildpackage which are able to generate the files
(orig.tar+debian.tar/diff) without using dpkg-source at all.
> I suspect 2.0 is entirely obsolete at this point;
It is. The manual page says "This format is not recommended for
wide-spread usage, the format "3.0 (quilt)" replaces it."
> and for most packages, it's better to choose "1.0" over "3.0 (native)"
> because it can be unpacked by more people; which mostly leaves the
3.0 (native) used with gzip compression will result in Format: 1.0
packages as they are exactly the same than native packages that we know
right now.
> manpage promoting "quilt" as the bestest version control format over git
> and bzr. Not impressive.
Urgh. I'm not promoting it as "version control format/system". I just
promote it as a good source package format: ie a snapshot of a software
that has been debianized.
> Heck, in /my/ opinion, all of 2.0, native, quilt and custom are less
> likely to be accepted on ftp-master as they currently stand -- native
> git and bzr support is a much bigger win than any of the others over
> what we can currently do.
I don't see any win over the current situation where packages are already
managed in git and debcheckout already gives you what you would get with
dpkg-source -x with the new source package format.
Yet we have enumerated quite a few drawbacks:
- full upload of the repository for each debian revision
- the added requirement of having several VCS to be able to unpack a
Debian most source package (it's unlikely at this stage to expect Debian
to standardize on a DVCS)
- the size increase due to the presence of the history (I know git is
efficient) that would force usage of shallow clones
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: