Re: non-free/contrib policy
> > Personally, I think it's a bit self-centered thinking of the
> > US-debianers to exportability from the US such a central issue
> > in determining wheter something can go into main or not. It'd
> > be much better to have a "Main" archive that includes the non-us
> > stuff, and provide an easy method for mirror administrators
> > to "ln -s export-restriction-README $filename" the files that
> > cannot be exported from that local mirror. That way, if the
> > Dutch gouverment is going to prohibit exportation of compilers,
> > and the French gouverment prohibits exportation of editors[1],
> > we will be ready[2] for that.
>
> Well said.
>
> The only problem is that I cannot see how to easily assemble the full
> distribution (i.e. US + non-US) with a couple of simple mirror configurations.
Well, at te moment it are apparently only 10 pacakges that are excluded
by the US government. So, for the US sites, just an
exclude_patt=^(bzip|ssh|pgp-us|pgp-i|cfs|ssleay|ssltelnet|rsaref)[_,\.]
would do it, I think (untested!).
But it'll be best to have a file in the archive somewhere "exclude-us",
and add an option "exclude_pat_file" to mirror that will read the
file (to be mirrored before the main stuff), and then list the
up-to-date exclude pattern in that "exclude-us" (or "exclude-netherlands",
when/if the Dutch are going to prohibit exportation of editors).
(and, that file can then be used to create symlinks after the mirror
was ran).
> So we would need to add these directories to both master and dresden archives:
>
> bo/binary-*/non-us
> bo/source/non-us
> contrib/binary-*/non-us
> contrib/source/non-us
> non-free/binary-*/non-us
> non-free/source/non-us
> hamm/hamm/binary-*/non-us
> hamm/hamm/source/non-us
> hamm/contrib/binary-*/non-us
> hamm/contrib/source/non-us
> hamm/non-free/binary-*/non-us
> hamm/non-free/source/non-us
>
> On the US, sites these directories would contain a README, but in dresden they
> would be populated by non-us maintainers uploading their packages.
At the moment this is a very good alternative. But still, it more-or
less criples the view of our tree for non-us citisens. Why cannot
I have bzip in /bo/source/utils/bzip, where it belongs? It's only
because the US (may) have strange copyright/patent laws, that the
us people want it in .../non-us. Same with ssl stuff[1].
And, what if the Dutch are indeed going to prohibit exportation
of compilers, would we add a directory bo/../non-dutch, and tell
all the US people "if you want gcc, no, it's not in /bo/.../devel,
it's in /bo/.../non-dutch"? I know the example is very strange,
but think about it: It is _excactly_ what the US people are now
telling me about the crypto stuff.
[1] Not sure about the copyright of ssl, but I thought it was
"Debian Free".
--
joost witteveen, joostje@debian.org
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: