Debian Policy 3.9.4.0 released
 

Quoting Russ Allbery (rra@debian.org):
> I've just uploaded Debian Policy 3.9.4.0, which includes the Technical
> Committee decision to make build-arch and build-indep mandatory targets
> (but not for wheezy; see below), a substantial rewrite of the section on
> shared library handling, and other changes to bring Policy closer to the
> current state of the archive.

Thanks again and again for the great work maintaining the policy (and
lintian as well).

Given the quite important change of making build-{arch,indep} targets
mandatory, wouldn't have been better to use something like 3.10.1 or
anything clearly saying "hey, there are not only minor changes here"?

(not sure wheter 3.10.1 > 3.9.4 but you probably get the point)

Debian Policy 3.9.4.0 released
 

Christian PERRIER <bubulle@debian.org> writes:

> Thanks again and again for the great work maintaining the policy (and
> lintian as well).

> Given the quite important change of making build-{arch,indep} targets
> mandatory, wouldn't have been better to use something like 3.10.1 or
> anything clearly saying "hey, there are not only minor changes here"?

> (not sure wheter 3.10.1 > 3.9.4 but you probably get the point)

Hm. You might be right; I didn't really think about it.

I will note, though, that I don't think this affects as many packages as
one might think. If you're using dh with a wildcard rule, you get this
for free. If you're using CDBS, I believe you already got this for free.
Most of the templates have included those targets for a long time, so
older debhelper packages already supported them.

Also, since dpkg has a workaround for this that will probably be
maintained for quite some time, there's no particular rush.

But yeah, in retrospect, with that and the symbols rewrite, this probably
should have been 3.10.0.0. Usually I'm better about incrementing version
numbers aggressively than that!

Well, I'll use that version once we get the multiarch changes in for sure.
:)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d31ia8re.fsf@windlord.stanford.edu">http://lists.debian.org/87d31ia8re.fsf@windlord.stanford.edu

Debian Policy 3.9.4.0 released
 

Russ Allbery writes ("Re: Debian Policy 3.9.4.0 released"):
> Well, I'll use that version once we get the multiarch changes in for sure.
> :)

4.x surely :-).

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20569.42786.474803.818201@chiark.greenend.org.uk"> http://lists.debian.org/20569.42786.474803.818201@chiark.greenend.org.uk

Debian Policy 3.9.4.0 released
 

Russ Allbery wrote:
> 7.8
> New `Built-Using' field, which must be used to document the
> source packages for any binaries that are incorporated into this
> package at build time. This is used to ensure that the archive
> meets license requirements for providing source for all binaries.

It seems that this was intended to apply to standalone binaries embedded
into things like d-i initrds (which already use it), but as it's written
it seems to apply to static linking of libraries as well.

That would include large numbers of haskell libraries and binaries that
statically link other haskell libraries. Even though most such
libraries actually have no source license requirements.
Hopefully a way can be found to automatically generate the field (or
dynamically link haskell..).

For that matter, don't all executables statically link to small portions
of libgcc and libc? It seems beyond redundant to require that be listed
every time.

--
see shy jo

Debian Policy 3.9.4.0 released
 

On Wed, 19 Sep 2012, Joey Hess wrote:
> Russ Allbery wrote:
> > 7.8
> > New `Built-Using' field, which must be used to document the
> > source packages for any binaries that are incorporated into this
> > package at build time. This is used to ensure that the archive
> > meets license requirements for providing source for all binaries.
>
> It seems that this was intended to apply to standalone binaries embedded
> into things like d-i initrds (which already use it), but as it's written
> it seems to apply to static linking of libraries as well.

This sort of sounds like Built-Using: only needs to contain things
which the package doesn't already Depends: (or perhaps even
Recommends:) on. [Which would resolve the archive licensing
requirements.]


Don Armstrong

--
America was far better suited to be the World's Movie Star. The
world's tequila-addled pro-league bowler. The world's acerbic bi-polar
stand-up comedian. Anything but a somber and tedious nation of
socially responsible centurions.
-- Bruce Sterling, _Distraction_ p122

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120919170139.GV8318@rzlab.ucr.edu">http://lists.debian.org/20120919170139.GV8318@rzlab.ucr.edu

Debian Policy 3.9.4.0 released
 

Hi,

On Wed, Sep 19, 2012 at 10:01:39AM -0700, Don Armstrong wrote:
> On Wed, 19 Sep 2012, Joey Hess wrote:
> > Russ Allbery wrote:
> > > 7.8
> > > New `Built-Using' field, which must be used to document the
> > > source packages for any binaries that are incorporated into this
> > > package at build time. This is used to ensure that the archive
> > > meets license requirements for providing source for all binaries.
> >
> > It seems that this was intended to apply to standalone binaries embedded
> > into things like d-i initrds (which already use it), but as it's written
> > it seems to apply to static linking of libraries as well.
>
> This sort of sounds like Built-Using: only needs to contain things
> which the package doesn't already Depends: (or perhaps even
> Recommends:) on.

He didn't deny that, but if you have static libs or header-only "libraries"
you don't have a Depends/Recommends: on the lib.

Regards,

Rene


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120919172427.GB3262@rene-engelhard.de">http://lists.debian.org/20120919172427.GB3262@rene-engelhard.de

Debian Policy 3.9.4.0 released
 

Joey Hess <joeyh@debian.org> writes:

> It seems that this was intended to apply to standalone binaries embedded
> into things like d-i initrds (which already use it), but as it's written
> it seems to apply to static linking of libraries as well.

> That would include large numbers of haskell libraries and binaries that
> statically link other haskell libraries. Even though most such
> libraries actually have no source license requirements.
> Hopefully a way can be found to automatically generate the field (or
> dynamically link haskell..).

> For that matter, don't all executables statically link to small portions
> of libgcc and libc? It seems beyond redundant to require that be listed
> every time.

Good point. Maybe we should say that Built-Using is only required if the
license requires that the source be available? (Not sure how to phrase
that.) The problem that it was trying to solve originally was fairly
specific to the GPL, IIRC.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mx0loq7u.fsf@windlord.stanford.edu">http://lists.debian.org/87mx0loq7u.fsf@windlord.stanford.edu

Debian Policy 3.9.4.0 released
 

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Re: Debian Policy 3.9.4.0 released"):

>> Well, I'll use that version once we get the multiarch changes in for
>> sure. :)

> 4.x surely :-).

Hm, I was hanging on to the 4.x version for rewriting the thing in DocBook
with corresponding significant organizational changes.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipb9oq72.fsf@windlord.stanford.edu">http://lists.debian.org/87ipb9oq72.fsf@windlord.stanford.edu

Debian Policy 3.9.4.0 released
 

Don Armstrong wrote:
> This sort of sounds like Built-Using: only needs to contain things
> which the package doesn't already Depends: (or perhaps even
> Recommends:) on. [Which would resolve the archive licensing
> requirements.]

To to usable to ensure GPL compliance, Built-Using needs to specify the
precise version of a package that is embedded into another.

So even though debian-installer Build-Depends: glibc-pic,
it still needs Built-Using: eglibc (= 2.13-35)

Russ Allbery wrote:
> Maybe we should say that Built-Using is only required if the
> license requires that the source be available? (Not sure how to phrase
> that.) The problem that it was trying to solve originally was fairly
> specific to the GPL, IIRC.

Makes sense to me, assuming the gcc runtime library exception
allows not providing source corresponding to the libgcc.a
linked into a binary.

(In practice, given the number of different gcc versions in the archive,
we probably have most of the sources covered.)

--
see shy jo

Debian Policy 3.9.4.0 released
 

Joey Hess <joeyh@debian.org> writes:
> Don Armstrong wrote:

>> This sort of sounds like Built-Using: only needs to contain things
>> which the package doesn't already Depends: (or perhaps even
>> Recommends:) on. [Which would resolve the archive licensing
>> requirements.]

> To to usable to ensure GPL compliance, Built-Using needs to specify the
> precise version of a package that is embedded into another.

> So even though debian-installer Build-Depends: glibc-pic,
> it still needs Built-Using: eglibc (= 2.13-35)

Yes. Built-Using has to be more precise than Build-Depends, so we can't
just rely on Build-Depends.

> Russ Allbery wrote:
>> Maybe we should say that Built-Using is only required if the license
>> requires that the source be available? (Not sure how to phrase that.)
>> The problem that it was trying to solve originally was fairly specific
>> to the GPL, IIRC.

> Makes sense to me, assuming the gcc runtime library exception allows not
> providing source corresponding to the libgcc.a linked into a binary.

It does.

You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if such
propagation would otherwise violate the terms of GPLv3, provided that
all Target Code was generated by Eligible Compilation Processes. You
may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules.

The definition of "Eligible Compilation Processes" is kind of complicated,
but it includes building with GCC or using a non-GCC compiler and
explicitly linking with libgcc.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipb9frvk.fsf@windlord.stanford.edu">http://lists.debian.org/87ipb9frvk.fsf@windlord.stanford.edu