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

Bug#556015: Clarify requirements for copyright file



On Mon, Jul 05, 2010 at 07:16:52PM -0700, Russ Allbery wrote:
> Don Armstrong <don@debian.org> writes:
> > On Sun, 04 Jul 2010, Russ Allbery wrote:

> >> Here's the question: should we say flat-out that both packages must
> >> either be architecture-dependent or architecture-independent and then
> >> say that the dependency must use (= <version>), or should we allow what
> >> I was trying to allow above and then document, such as in a footnote,
> >> the technique of depending on (>= <version>), (<< <version>+b99)? The
> >> latter, as mentioned, may hide binNMU changelog entries.

> > The changelog really documents the changes in the versions of the source
> > package, not changes in the binary package.

> Well, they do, in that binNMUs do change the changelog included in the
> package.  I'm inclined to agree that it's not a big deal if we lose that
> information in the installed package, though.

Well, the binary package changelog is the *only* place this information is
captured that the average user/developer can get at it.  (It's stored in
wanna-build's db and it's in the .changes file that's archived on
ftp-master, but since these are binary uploads it's not even posted to
debian-devel-changes - if you even knew where to look in that haystack).  I
would think that we care about users being able to see why a package is
being upgraded on their system, don't we?

OTOH, thinking ahead a little bit, if we *do* insist on requiring changelog
entries for binNMUs in the package that may make things interesting for
multiarch.  Since binNMUS are per-architecture, binNMUS on two architectures
may have the same version but different changelog entries, making it
impossible to share the /usr/share/doc/ directory between archs for these
packages.  Maybe the answer there is to have a policy of always binNMUing
multiarch packages in lockstep; I don't think the alternative of
*requiring* multiarch packages to symlink to an arch: all package for their
changelogs makes much sense.

> any -> any can use (= ${binary:Version})
> any -> all can use (= ${source:Version})
> all -> all can use (= ${source:Version})

> The question is what to do for all -> any.  Right now, I think best
> practice is to do something like:

>     (>= ${source:Version}), (<< ${source:Version}+b99)

<< ${source:Version}+c ?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: