Deprecating the wiki-based Packaging Guide

Scott Kitterman ubuntu at kitterman.com
Wed Dec 19 02:33:18 UTC 2012


Steve Langasek <steve.langasek at ubuntu.com> wrote:

>On Tue, Dec 18, 2012 at 09:09:39PM -0500, Scott Kitterman wrote:
>
>> I find the interfaces to the UDD tools very confusing. Here's but one
>> example (yes, I filed a bug, no I don't recall the number):
>> 
>> The basic dpkg-buildpackage command to build a source package that
>will
>> include the upstream tarball in the upload is:
>> 
>> dpkg-buildpackage -S -sa
>> 
>> For the non-UDD dpkg-buildpackage wrapper debuild, one attaches
>> dpkg-buildpackage options on the end and they are passed to
>> dpkg-buildpackage:
>> 
>> debuild -S -sa
>> 
>> bzr-builddeb has this interface:
>> 
>> bzr-builddeb -S -- -sa
>
>'bzr bd -- -S -sa' works equally well, and could be the usage
>recommended in
>the documentation for consistency.
>
>> The biggest benefit of UDD, IMO is that each upload is imported into
>a VCS
>> so we have per upload history.  That happens no matter how the
>package is
>> built or uploaded.  All the additional complexity of committing to
>the VCS
>> and getting that merged has very minimal benefits for the average
>> developer.
>
>One concrete example where UDD shines and the non-UDD workflow is
>inadequate
>is for sponsoring of package merges.  If someone hands me a branch that
>properly merges the new Debian version into the Ubuntu branch, I can
>review
>that with the standard bzr diff tools and ascertain that the sponsoree
>has
>done the merge correctly.  If someone hands me a debdiff for a Debian
>merge,
>that's useless; I effectively have to do the merge myself as part of
>the
>review, and no time is saved.

It only works better if you are using UDD.  I agree that if your primary workflow is UDD based, then UDD branches are better.  If I get a branch it's as useless for me as a debdiff is for you.  When asked to sponsor things that have a branch, I generally decline or ask for a debdiff.

 Scott K




More information about the ubuntu-devel mailing list