Deprecating the wiki-based Packaging Guide

[Scott Kitterman]

Mike Carifio <carifio at usys.com> wrote:

>On 12/18/2012 05:48 PM, Scott Kitterman wrote:
>> Barry Warsaw <barry at ubuntu.com> wrote:
>>
>>> On Dec 17, 2012, at 07:52 PM, Scott Kitterman wrote:
>>>
>>>> UDD is not mature or reliable enough to be presented to new users
>as
>>> "the"
>>>> way to do packaging for Ubuntu.  I think the current guide is
>fatally
>>> flawed
>>>> as is.
>>> Yes, it's frustrating when you need to work on a package that has
>>> import
>>> failures, and yes, I wish we had more cycles to devote to fixing
>this,
>>> but the
>>> majority of packages import just fine, and UDD (IMHO and YMMV) has
>>> enormous
>>> benefits which outweigh those frustrations.
>>>
>>> Of course, I'm not saying that traditional packaging shouldn't also
>be
>>> described.
>>>
>>> -Barry
>> It seems obvious to me that the standard approach ought to be the
>reliable one.  Making the UDD based approach 'normal' ensures people
>need to know two ways to do it and for introductory material, I think
>that is clearly suboptimal.
>>
>> Also, I think the benefits primarily accrue to people that use UDD a
>lot.  The benefits to people that don't use it quite regularly are
>minimal.  This reinforces the idea it's not the right default to
>present.
>>
>> Finally, it's a more complex toolset that raises the barrier to entry
>for newcomers.  I don't think that's what we want.
>>
>> Scott K
>
>I don't mean to be argumentative, but none of that seems obvious to me.
>If UDD is a better workflow when it works, then fix it until it works.
>Then describe it so it makes sense. Then use it consistently to improve
>the ecosystem. That will make it the default. Right now, we seem to
>have
>to work with debian source packages so we can feed the build system but
>work with a version control system to "upstream" changes in a
>productive
>way. That seems suboptimal too.
>
>I'm the first person to admit that I probably don't get it yet or see
>the obstacles to UDD utopia. But not using a
>version control tool for a source code control problem doesn't make
>sense either.

Downloading a Debian source package or even a source package and a Debian only bzr branch (as the Kubuntu team does) is much faster than downloading full source bzr branches.  Unless someone works with a specific package routinely, full source branches slow the process up significantly.

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

Go figure that one out (yes, I understand it and why, but I think it's a user hostile interface design).

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.

The people you see advocating that UDD has great advantage for them are ~all people who do this full time and can live in the UDD environment.  They aren't the target audience for the packaging guide.

I think the lack of reliability argument is sufficient for now to make the case that UDD should not be the 'normal' method taught to new people.  Even if that weren't the case though, I would still think the added leaving curve coupled with creating a barrier to collaboration with our primary upstream would mean it's still not a good idea.

Scott K