Re: summary of non-free/contrib policy

[Philip Hands <phil@hands.com>]

> As to your position that one country's laws should not affect our
> distribution setup, it is admirable but unpragmatic.

This argument is being clouded by the overloading of the term ``main''

Definitions:

main(1) -- the packages that are allowed in the main directory on master

main(2) -- the packages that fully comply with the DFSG (including
           dependencies etc.)

I think that the second definition is more useful for policy discussions, 
since it is unaffected by laws (that may change), or by the fact that master 
might be relocated to a different country at some point in the future.

This definition allows us to state the policy fairly simply:

  The main(2) distribution shall contain only packages that comply with the
  DFSG, are buildable using only main(2) packages, and depend upon or require
  only main(2) packages.

  In some countries, not all main(2) packages can be published for legal
  reasons, so only a partial copy of the main(2) distribution will be available
  on servers in those countries.

  This partial copy should still be internally consistent, and so cannot
  include packages that depend upon or require the locally unpublishable
  packages.

The main implication of this is that DFSG packages that depend on export 
restricted software are considered to be main(2) packages, but cannot be put 
in the main directory on master, so should go wherever main(2) packages go 
outside the US.  Not into contrib.

Now we come to implementing the policy.  Obviously the simplest thing is to 
leave it mostly as it is.  The only change required is to make it possible to 
merge US-main and Non-US-main to result in a distribution that matches the 
main(2) definition.

I don't think there is any need to actually merge the directory structure, as 
long as a non-US CD manufacturer can easily produce the complete main(2) CD, 
and the user of that CD doesn't notice the join.

To achieve that, we need to have dselect pick up on the fact that there is a 
non-us directory around, and we need to split the non-us packages into main 
and non-free (or contrib, lets not get into that ;-).

Alternatively, we could have the export restricted packages be represented by 
symbolic links in the main directory (both in and out of the US), but have the 
thing they point at be a stub package on the US sites.

This is more elegant, since it would handle the vagaries of e.g. French law 
etc. etc.

Since most (all?) of the packages in question are allowed to be imported into 
the US, we could make the stub package(s) on the US sites be something that 
lets the user grab a copy of the real package from a non-US archive via ftp.

For example we could structure it thus:

  hamm/hamm/binary-i386/admin/cfs_1.3.3-1.deb ->
      ../../../../non-us/hamm/hamm/binary-i386/cfs_1.3.3-1.deb

on a non-US site non-us/hamm/hamm/binary-i386/cfs_1.3.3-1.deb would be the 
real file.

on master it might be:

  non-us/hamm/hamm/binary-i386/cfs_1.3.3-1.deb -> us-only-stub_1.0.deb

or a copy of the appropriate stub package, installed automatically with the 
correct name.

This structure would allow simple mirroring.  You could pick up the main 
distribution from a US site (less the non-us directory), and drop in the real 
non-us directory.

One thing I'm not sure about is how to make uploads to non-us sites update the 
links to master.  Another is that non-us should probably be called non-global 
or something, to cover the non-french possibility.

Cheers, Phil.



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .