Deprecating the wiki-based Packaging Guide

[Barry Warsaw]

On Jan 09, 2013, at 09:03 AM, Martin Pitt wrote:

>IMHO the main obstacle is that UDD does not work well for common use
>cases.  I find myself not exactly liking UDD even for the (vast
>majority of) packages where the branches are up to date, mostly
>because its design is a bit upside down: It has pretty much perfect
>VCS behaviour for precisely those bits which we do not want to change
>in a distro: the original upstream source. For changing them, we need
>to use quilt and debian/patches/, which is the very same approach than
>with plain apt-get source, except that UDD imposes a lot of extra
>overhead: I have to take care to pre-apply patches, add/track all the
>extra .pc stuff, do things three times in a row until the pre-applied
>patches stop conflicting with the operation that I'm currently doing
>(new upstream source, editing or adding a patch), etc.

Yeah, I get that.  FWIW, I have a successful workflow for quilt branches that
isn't very painful, and does benefit from having the full source package under
bzr.  I've mentioned it before on this list, but I should probably update the
packaging guide.  A couple of rules:

1) Always commit with your quilt stack at the same level as the original
   branch.  This usually means popping your last patch before you commit.

2) Never push your branch back to Launchpad.  Upload it as normal and let the
   package importer do all the merge magic.

What I like about UDD for quilt branches is that I don't have to worry much
about generating the patch.  I can mostly edit the original source and use
`bzr diff` to generate the first quilt patch.  From there, I generally use
quilt command to refresh the patch until it's ready.  Rule #1 above will leave
you with a clean upstream source tree and the new quilt patch (which of course
you have to `bzr add`).

And of course using bzr works great when you're hacking in debian/.

Could it work better?  Yes, definitely.  It's been discussed for years now.
*Will* it get better?  I can't answer that. :)

>Also, UDD is incompatible with having upstream develop on Launchpad as
>the branches share no history and thus you can't just "bzr merge
>lp:trunk" for a new upstream version, cherrypick changes, etc.
>This breaks a lot of the reasons why one wants to use a VCS in the
>first place.

Highly agreed here.  I can see that desktop would feel this pain more acutely.

>Now, those two things (patching packages and working with packages
>whose upstream is on LP) is, or at least had been for many years, my
>bread and butter of what I do in Ubuntu. This might be different for
>other people who mostly work on packaging or native packages; UDD
>works well for both cases, and I like those branches myself as well
>for those cases.
>
>But these are the reasons why the desktop team doesn't use UDD: one
>half of our packages has upstreams on LP (indicators, Unity,
>software-center, etc.), and the main exercise on other half (GNOME) is
>patching and upstream version updates, not changing packaging.
>
>So in summary, I think the packaging documentation should certainly
>explain UDD, but at least point out that some packages are maintained
>differently (point out https://wiki.ubuntu.com/DesktopTeam/Bzr, the
>Vcs-Bzr: field, and apt-get source).

stokachu mentioned that Fedora uses a dvcs (git?) to do a lot of their package
management and that their workflow is well integrated with the build system.
I could have that totally wrong, as I have no experience with it, but I still
firmly believe that package management should be well integrated with a dvcs.
It's usable in a lot of cases for Ubuntu today with UDD, but it clearly has
yet to realize its full potential.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130109/f2eb4646/attachment.pgp>