Bug#770016: Clarify network access for building packages in main

2015-04-29 Thread Bill Allombert
On Mon, Feb 16, 2015 at 12:08:25AM +0100, Bill Allombert wrote:
 On Wed, Feb 04, 2015 at 10:08:50AM -0200, Henrique de Moraes Holschuh wrote:
  On Tue, Feb 3, 2015, at 20:21, Bill Allombert wrote:
   On Tue, Feb 03, 2015 at 04:27:56PM +0100, Lucas Nussbaum wrote:

yeah, I second this version:
 +  For packages in the main archive, no required targets
 +  may attempt network access.
   
   Henrique, did Lucas answers about the archive rebuild address your
   objections ?
  
  Yes.  We can treat exceptions as... exceptions :-)
 
 Excellent, so I have created a GIT branch bug770016-bill with the patch below
 that I will commit in a few days.

Done. Sorry for the delay, my hard disk went dead shortly after this.
Recovering now.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2015-02-15 Thread Bill Allombert
On Wed, Feb 04, 2015 at 10:08:50AM -0200, Henrique de Moraes Holschuh wrote:
 On Tue, Feb 3, 2015, at 20:21, Bill Allombert wrote:
  On Tue, Feb 03, 2015 at 04:27:56PM +0100, Lucas Nussbaum wrote:
   
   yeah, I second this version:
+  For packages in the main archive, no required targets
+  may attempt network access.
  
  Henrique, did Lucas answers about the archive rebuild address your
  objections ?
 
 Yes.  We can treat exceptions as... exceptions :-)

Excellent, so I have created a GIT branch bug770016-bill with the patch below
that I will commit in a few days.

Cheers
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
commit d6fe14c1c08cea5adecd5006da900e12511beff5
Author: Bill Allombert bill.allomb...@math.u-bordeaux1.fr
Date:   Sun Nov 23 17:39:21 2014 +0100

Policy: [4.9] debian/rules: required targets must not attempt network 
access.

Wording:  Bill  Allombert ballo...@debian.org
Seconded: Andrey Rahmatullin w...@debian.org
Seconded: Lucas Nussbaum lu...@debian.org
Closes: #770016

diff --git a/debian/changelog b/debian/changelog
index 93cf4f7..5deadec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,6 +19,11 @@ debian-policy (3.9.7.0) unstable; urgency=low
 Seconded: Henrique de Moraes Holschuh h...@debian.org
 Seconded: Andrey Rahmatullin w...@debian.org
 Closes: #666726
+  * Policy: [4.9] debian/rules: required targets must not attempt network 
access.
+Wording:  Bill  Allombert ballo...@debian.org
+Seconded: Andrey Rahmatullin w...@debian.org
+Seconded: Lucas Nussbaum lu...@debian.org
+Closes: #770016
 
  -- Bill Allombert ballo...@debian.org  Sun, 08 Feb 2015 19:22:01 +0100
 
diff --git a/policy.sgml b/policy.sgml
index 4adee0b..a8afd41 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1931,6 +1931,10 @@ zope.
  any target that these targets depend on must also be
  non-interactive.
/p
+   p
+  For packages in the main archive, no required targets
+  may attempt network access.
+   /p
 
p
  The targets are as follows:
diff --git a/upgrading-checklist.sgml b/upgrading-checklist.sgml
index 7e490e6..7aa17a8 100644
--- a/upgrading-checklist.sgml
+++ b/upgrading-checklist.sgml
@@ -49,6 +49,9 @@ Released xxx, 2015.
 tag5.1/tag
   item Empty field values in control files are only permitted in the
   filedebian/control/file file of a source package.
+tag4.9/tag filedebian/rules/file: required targets must not attempt
+  network access.
+  item  
   /item /taglist/p
 
 sect id=3.9.6.0 Version 3.9.6.0


Bug#770016: Clarify network access for building packages in main

2015-02-03 Thread Lucas Nussbaum
On 31/01/15 at 20:47 +0100, Bill Allombert wrote:
 On Mon, Nov 24, 2014 at 10:21:27AM +0100, Lucas Nussbaum wrote:
  On 23/11/14 at 21:13 +0100, Bill Allombert wrote:
   Was there a lot of failure ?
  
  No
  
   What severity did you use for the bug report ?
  
  serious
 
 So in practice, this is already handled as a RC bug. Good.
 
   Are you in favor of the patch above ?
  
  In general, yes.
 
 So are you willing to second it ?

yeah, I second this version:
 +  For packages in the main archive, no required targets
 +  may attempt network access.

even if I would prefer something that did not restrict to main, and said
something like:

  No packages may rely on network access to be available during the execution
  of required targets.

Lucas


signature.asc
Description: Digital signature


Bug#770016: Clarify network access for building packages in main

2015-02-03 Thread Bill Allombert
On Tue, Feb 03, 2015 at 04:27:56PM +0100, Lucas Nussbaum wrote:
 
 yeah, I second this version:
  +  For packages in the main archive, no required targets
  +  may attempt network access.
 
 even if I would prefer something that did not restrict to main, and said
 something like:
 
   No packages may rely on network access to be available during the execution
   of required targets.

I have no problem removing the restriction to the main archive.
(non free is always an exception to policy anyway).

However as I understand, your wording still allow to use network access if it
is available (which I find dangerous).

Maybe 
   The execution of a required target must not attempt network access.

Henrique, did Lucas answers about the archive rebuild address your objections ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2015-01-31 Thread Bill Allombert
On Mon, Nov 24, 2014 at 10:21:27AM +0100, Lucas Nussbaum wrote:
 On 23/11/14 at 21:13 +0100, Bill Allombert wrote:
  Was there a lot of failure ?
 
 No
 
  What severity did you use for the bug report ?
 
 serious

So in practice, this is already handled as a RC bug. Good.

  Are you in favor of the patch above ?
 
 In general, yes.

So are you willing to second it ?

 I wonder if it should be turned into the package must not rely on
 external access network to build correctly. A package that checks if
 network access is available, and run more tests if it's the case, could
 be fine.

This would violate the principle of least surprise.
A package might FTBFS in some circumstance, and not in another.
We can aways add exceptions later.

I would like to move on with this issue, and welcome seconds.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-25 Thread Jakub Wilk
[Let's leave the problem of d-i aside for the moment. I suppose it'll 
require a special exception in Policy, at least for the time being.]


* Lucas Nussbaum lu...@debian.org, 2014-11-24, 10:21:
I wonder if it should be turned into the package must not rely on 
external access network to build correctly.


That's better than nothing, but...

A package that checks if network access is available, and run more 
tests if it's the case, could be fine.


I, for one, would consider my package RC buggy if it tried to use 
external network, even if such access had no influence on the resulting 
binary packages.


I do appreciate that having tests that require network connectivity is 
useful for some packages. We could add an option for DEB_BUILD_OPTIONS 
to let users opt-in for such tests.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-24 Thread Lucas Nussbaum
On 23/11/14 at 21:13 +0100, Bill Allombert wrote:
 On Sun, Nov 23, 2014 at 08:15:33PM +0100, Lucas Nussbaum wrote:
  On 23/11/14 at 20:03 +0100, Bill Allombert wrote:
   On Sun, Nov 23, 2014 at 04:47:00PM -0200, Henrique de Moraes Holschuh 
   wrote:
On Sun, 23 Nov 2014, Bill Allombert wrote:
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -1928,12 +1928,16 @@ zope.
 impossible to auto-compile that package and also makes it hard
 for other people to reproduce the same binary package, all
 required targets must be non-interactive.  It also follows 
 that
 any target that these targets depend on must also be
 non-interactive.
   /p
 + p
 +  For packages in the main archive, no required targets
 +  may attempt network access.
 + /p
  
   p
 The targets are as follows:
 taglist
   tagttbuild/tt (required)/tag
   item

This is something we want for multiple reasons, but have we already 
fixed
all instances of, e.g., validating sgml/xml parsers trying to fetch 
DTDs or
schemas during documentation build ?  Or other network access attempts 
that
don't fail a build (and helpfully don't modify it either)?
   
   Lucas, can you confirm that the main archive ca be rebuild without 
   external
   network access ?
  
  No: that's something I used to check (by building on machines with
  specific firewall rules to forbid external network access), but that I
  haven't been testing recently.
 
 Was there a lot of failure ?

No

 What severity did you use for the bug report ?

serious

 Are you in favor of the patch above ?

In general, yes.
I wonder if it should be turned into the package must not rely on
external access network to build correctly. A package that checks if
network access is available, and run more tests if it's the case, could
be fine.

Lucas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Bill Allombert
On Tue, Nov 18, 2014 at 03:03:07PM +0600, Andrey Rahmatullin wrote:
 Package: debian-policy
 Severity: wishlist
 
 2.2.1 says the packages in main
 
must not require or recommend a package outside of main for compilation or
 execution (thus, the package must not declare a Pre-Depends, Depends,
 Recommends, Build-Depends, or Build-Depends-Indep relationship on a non-
 main package),
 
 In practice there is a consensus that this also means packages must not 
 access
 external network servers which conforms to the spirit but not to the letter 
 of
 this section.

I offer the attached patch, which target section
4.9 Main building script: debian/rules

This only address the issue in the bug title, namely
'Clarify network access for building packages in main'.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
diff --git a/policy.sgml b/policy.sgml
index 7bb703b..107ee44 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1928,12 +1928,16 @@ zope.
  impossible to auto-compile that package and also makes it hard
  for other people to reproduce the same binary package, all
  required targets must be non-interactive.  It also follows that
  any target that these targets depend on must also be
  non-interactive.
/p
+   p
+  For packages in the main archive, no required targets
+  may attempt network access.
+   /p
 
p
  The targets are as follows:
  taglist
tagttbuild/tt (required)/tag
item


Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Andrey Rahmatullin
On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote:
  2.2.1 says the packages in main
  
 must not require or recommend a package outside of main for compilation 
  or
  execution (thus, the package must not declare a Pre-Depends, Depends,
  Recommends, Build-Depends, or Build-Depends-Indep relationship on a 
  non-
  main package),
  
  In practice there is a consensus that this also means packages must not 
  access
  external network servers which conforms to the spirit but not to the 
  letter of
  this section.
  
  Note that there may be other requirements which are not codified, as 
  mentioning
  only things that are packaged is not enough, it should say something like 
  must
  not use any stuff except for packages in main.
 
 Hi Andrew,
 
 I guess that it is implicit from the defintion of contrib that follows in 
 2.2.2:
 
   The contrib archive area contains supplemental packages intended to work 
 with
   the Debian distribution, but which require software outside of the 
 distribution
   to either build or function. 
I've just understood both these statements mention requiring something
non-free to *function*.
Do we allow packages in main to require external services to function?

-- 
WBR, wRAR


signature.asc
Description: Digital signature


Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Andrey Rahmatullin
On Sun, Nov 23, 2014 at 05:38:50PM +0100, Bill Allombert wrote:
  Package: debian-policy
  Severity: wishlist
  
  2.2.1 says the packages in main
  
 must not require or recommend a package outside of main for compilation 
  or
  execution (thus, the package must not declare a Pre-Depends, Depends,
  Recommends, Build-Depends, or Build-Depends-Indep relationship on a 
  non-
  main package),
  
  In practice there is a consensus that this also means packages must not 
  access
  external network servers which conforms to the spirit but not to the 
  letter of
  this section.
 
 I offer the attached patch, which target section
 4.9 Main building script: debian/rules
 
 This only address the issue in the bug title, namely
 'Clarify network access for building packages in main'.
 
 Cheers,

 diff --git a/policy.sgml b/policy.sgml
 index 7bb703b..107ee44 100644
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -1928,12 +1928,16 @@ zope.
 impossible to auto-compile that package and also makes it hard
 for other people to reproduce the same binary package, all
 required targets must be non-interactive.  It also follows that
 any target that these targets depend on must also be
 non-interactive.
   /p
 + p
 +  For packages in the main archive, no required targets
 +  may attempt network access.
 + /p
  
   p
 The targets are as follows:
 taglist
   tagttbuild/tt (required)/tag
   item
It's fine, as it solves the initial problem. Seconded.

-- 
WBR, wRAR


signature.asc
Description: Digital signature


Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Henrique de Moraes Holschuh
On Sun, 23 Nov 2014, Bill Allombert wrote:
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -1928,12 +1928,16 @@ zope.
 impossible to auto-compile that package and also makes it hard
 for other people to reproduce the same binary package, all
 required targets must be non-interactive.  It also follows that
 any target that these targets depend on must also be
 non-interactive.
   /p
 + p
 +  For packages in the main archive, no required targets
 +  may attempt network access.
 + /p
  
   p
 The targets are as follows:
 taglist
   tagttbuild/tt (required)/tag
   item

This is something we want for multiple reasons, but have we already fixed
all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or
schemas during documentation build ?  Or other network access attempts that
don't fail a build (and helpfully don't modify it either)?

I worry that we'd might need an intermediate step.

And it is is not just for main, I don't think contrib is supposed to hit the
network during *build*, either.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Bill Allombert
On Sun, Nov 23, 2014 at 10:52:54PM +0500, Andrey Rahmatullin wrote:
 On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote:
   2.2.1 says the packages in main
   
  must not require or recommend a package outside of main for 
   compilation or
   execution (thus, the package must not declare a Pre-Depends, Depends,
   Recommends, Build-Depends, or Build-Depends-Indep relationship on a 
   non-
   main package),
   
   In practice there is a consensus that this also means packages must not 
   access
   external network servers which conforms to the spirit but not to the 
   letter of
   this section.
   
   Note that there may be other requirements which are not codified, as 
   mentioning
   only things that are packaged is not enough, it should say something like 
   must
   not use any stuff except for packages in main.
  
  Hi Andrew,
  
  I guess that it is implicit from the defintion of contrib that follows in 
  2.2.2:
  
The contrib archive area contains supplemental packages intended to work 
  with
the Debian distribution, but which require software outside of the 
  distribution
to either build or function. 
 I've just understood both these statements mention requiring something
 non-free to *function*.
 Do we allow packages in main to require external services to function?

There are far too many special case (think: whois, DNS, youtube-dl)
to write something meaningful I am afraid.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Bill Allombert
On Sun, Nov 23, 2014 at 04:47:00PM -0200, Henrique de Moraes Holschuh wrote:
 On Sun, 23 Nov 2014, Bill Allombert wrote:
  --- a/policy.sgml
  +++ b/policy.sgml
  @@ -1928,12 +1928,16 @@ zope.
impossible to auto-compile that package and also makes it hard
for other people to reproduce the same binary package, all
required targets must be non-interactive.  It also follows that
any target that these targets depend on must also be
non-interactive.
  /p
  +   p
  +  For packages in the main archive, no required targets
  +  may attempt network access.
  +   /p
   
  p
The targets are as follows:
taglist
  tagttbuild/tt (required)/tag
  item
 
 This is something we want for multiple reasons, but have we already fixed
 all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or
 schemas during documentation build ?  Or other network access attempts that
 don't fail a build (and helpfully don't modify it either)?

Lucas, can you confirm that the main archive ca be rebuild without external
network access ?

 And it is is not just for main, I don't think contrib is supposed to hit the
 network during *build*, either.

I have no idea abut contrib.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Cyril Brulebois
Bill Allombert ballo...@debian.org (2014-11-23):
  This is something we want for multiple reasons, but have we already fixed
  all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or
  schemas during documentation build ?  Or other network access attempts that
  don't fail a build (and helpfully don't modify it either)?
 
 Lucas, can you confirm that the main archive ca be rebuild without external
 network access ?

Depends what you call “external network access”. At least the
debian-installer source package pulls stuff from a mirror doing
the build.

(No need to tell me how wrong, ugly, blablabla that is; I'm aware.)

Mraw,
KiBi.


signature.asc
Description: Digital signature


Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Lucas Nussbaum
On 23/11/14 at 20:03 +0100, Bill Allombert wrote:
 On Sun, Nov 23, 2014 at 04:47:00PM -0200, Henrique de Moraes Holschuh wrote:
  On Sun, 23 Nov 2014, Bill Allombert wrote:
   --- a/policy.sgml
   +++ b/policy.sgml
   @@ -1928,12 +1928,16 @@ zope.
   impossible to auto-compile that package and also makes it hard
   for other people to reproduce the same binary package, all
   required targets must be non-interactive.  It also follows that
   any target that these targets depend on must also be
   non-interactive.
 /p
   + p
   +  For packages in the main archive, no required targets
   +  may attempt network access.
   + /p

 p
   The targets are as follows:
   taglist
 tagttbuild/tt (required)/tag
 item
  
  This is something we want for multiple reasons, but have we already fixed
  all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or
  schemas during documentation build ?  Or other network access attempts that
  don't fail a build (and helpfully don't modify it either)?
 
 Lucas, can you confirm that the main archive ca be rebuild without external
 network access ?

No: that's something I used to check (by building on machines with
specific firewall rules to forbid external network access), but that I
haven't been testing recently.

In the past, the rebuild setup was on a platform where external network
access was unavailable; but now that it moved to Amazon, this is no
longer a problem, and I haven't re-implemented the firewall rules.

Lucas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-23 Thread Bill Allombert
On Sun, Nov 23, 2014 at 08:15:33PM +0100, Lucas Nussbaum wrote:
 On 23/11/14 at 20:03 +0100, Bill Allombert wrote:
  On Sun, Nov 23, 2014 at 04:47:00PM -0200, Henrique de Moraes Holschuh wrote:
   On Sun, 23 Nov 2014, Bill Allombert wrote:
--- a/policy.sgml
+++ b/policy.sgml
@@ -1928,12 +1928,16 @@ zope.
  impossible to auto-compile that package and also makes it hard
  for other people to reproduce the same binary package, all
  required targets must be non-interactive.  It also follows 
that
  any target that these targets depend on must also be
  non-interactive.
/p
+   p
+  For packages in the main archive, no required targets
+  may attempt network access.
+   /p
 
p
  The targets are as follows:
  taglist
tagttbuild/tt (required)/tag
item
   
   This is something we want for multiple reasons, but have we already fixed
   all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs 
   or
   schemas during documentation build ?  Or other network access attempts 
   that
   don't fail a build (and helpfully don't modify it either)?
  
  Lucas, can you confirm that the main archive ca be rebuild without external
  network access ?
 
 No: that's something I used to check (by building on machines with
 specific firewall rules to forbid external network access), but that I
 haven't been testing recently.

Was there a lot of failure ? What severity did you use for the bug report ?
Are you in favor of the patch above ?
I think it reflect the general view and practice.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-18 Thread Andrey Rahmatullin
Package: debian-policy
Severity: wishlist

2.2.1 says the packages in main

   must not require or recommend a package outside of main for compilation or
execution (thus, the package must not declare a Pre-Depends, Depends,
Recommends, Build-Depends, or Build-Depends-Indep relationship on a non-
main package),

In practice there is a consensus that this also means packages must not access
external network servers which conforms to the spirit but not to the letter of
this section.

Note that there may be other requirements which are not codified, as mentioning
only things that are packaged is not enough, it should say something like must
not use any stuff except for packages in main.



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-18 Thread Charles Plessy
Le Tue, Nov 18, 2014 at 03:03:07PM +0600, Andrey Rahmatullin a écrit :
 
 2.2.1 says the packages in main
 
must not require or recommend a package outside of main for compilation or
 execution (thus, the package must not declare a Pre-Depends, Depends,
 Recommends, Build-Depends, or Build-Depends-Indep relationship on a non-
 main package),
 
 In practice there is a consensus that this also means packages must not 
 access
 external network servers which conforms to the spirit but not to the letter 
 of
 this section.
 
 Note that there may be other requirements which are not codified, as 
 mentioning
 only things that are packaged is not enough, it should say something like 
 must
 not use any stuff except for packages in main.

Hi Andrew,

I guess that it is implicit from the defintion of contrib that follows in 2.2.2:

  The contrib archive area contains supplemental packages intended to work with
  the Debian distribution, but which require software outside of the 
distribution
  to either build or function. 

This said, one could argue that the definition of main should not depend on the
definition of contrib or non-free...

Would you, Holger or somebody else propose a patch ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-18 Thread Andrey Rahmatullin
On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote:
 I guess that it is implicit from the defintion of contrib that follows in 
 2.2.2:
 
   The contrib archive area contains supplemental packages intended to work 
 with
   the Debian distribution, but which require software outside of the 
 distribution
   to either build or function. 
I have a feeling that software here is too narrow.

-- 
WBR, wRAR


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770016: Clarify network access for building packages in main

2014-11-18 Thread Henrique de Moraes Holschuh
On Tue, 18 Nov 2014, Andrey Rahmatullin wrote:
 On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote:
  I guess that it is implicit from the defintion of contrib that follows in 
  2.2.2:
  
The contrib archive area contains supplemental packages intended to work 
  with
the Debian distribution, but which require software outside of the 
  distribution
to either build or function. 
 I have a feeling that software here is too narrow.

Well, contrib is also used when there is a requirement of *data* (be it game
assets or scientific datasets) external to Debian main, not just software.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org