[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: Handling of changelog bug closures in Debian derived distros

On Tue, 2006-11-14 at 13:35:00 -0800, Matt Zimmerman wrote:
> On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote:
> >  * Using a different "Closes:" name, which just sidetracks the issue
> >    if every derivative have to use a different name, this does not
> >    scale. (Example: Maemo uses "Fixes:" instead of "Closes:" [1],
> >    and there's a proposal in Ubuntu to do something similar with
> >    a different name[3]).
> FTR, the syntax agreed upon for Launchpad (and thus Ubuntu) is:
> LP: #xxx
> which is not arbitrary or ambiguous like fixes vs. closes.

The main problem with this form of abbreviation is that it needs some
kind of centralized place to define the meaning, it could mean
LinsPire, for example. ;)

> > [...]
> > which are wrong, ugly or may need a central registration place to avoid
> > collisions either in the mnemonic or the "alternative" closure syntax.
> > Probably the cleanest one is the "Closes Ubuntu:" approach.
> I don't see a problem with the approach we've chosen for Launchpad (which
> will also cover several Ubuntu derivatives).

Even in expanded form "Launchpad: #12345" I think it's a bad choice,
because it forces dpkg to be aware of which bug tracking system the
distribution is using. It also locks that distribution to a specific

I don't want to add support for every BTS out there to dpkg-dev, that's
why we have the Bugs field and the /etc/dpkg/origins/ files. And with
the origin option, that's taken care in a generic way.

> Likewise, I think that qualifying it with the distribution name is perfectly
> OK; that's already unique enough.

If by "qualifying it" you mean something like "Closes Ubuntu:" then I
think that'd be an improvement over the other one and I stated that in
my original proposal, but then you have to duplicate that information
into each closure line.

> > So I'd propose to extend the changelog format to add an optional origin
> > field in the header, then that information will be preserved after the
> > upload. Something like this:
> > 
> > foo (1.0-2naibed2) quux; urgency=low, origin=naibed
> > [...]
> I think this is a fine idea, though orthogonal to what we're doing with
> Launchpad references in changelogs.

I don't see how they are orthogonal.

> > That origin could be matched against /etc/dpkg/origins. I'm attaching a
> > PoC patch with those change to dpkg. Probably we'd not want to output the
> > Origin field in the default mode (assuming Debian or local), instead of
> > the current implementation which outputs "Origin: debian".  So comments
> > and other proposals welcome!
> I didn't see the patch,

Sorry, forgot to attach it in my first mail, but replied to myself


> but bear in mind that it's not unusual to upload a
> package to Debian from an Ubuntu system or vice versa.

That's taken into account by the current patch already. The Closes
field in the .changes file, will include, only the closures for all
entries matching the same origin as the topmost entry in the changelog
file, given the range from the -v option, if specified. To allow this
kind of mixed changelogs in Debian, debbugs changelog parsing would
need patching, though.


Reply to: