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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
