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

Re: non-free/contrib policy



I said:

>   It seems like the primary ftp site should be outside the U.S.
>   Then, the crypto stuff could be on it and everyone (both inside
>   and outside the U.S.) could download from it.  Also, U.S. mirrors
>   could download from that site, and U.S. downloaders could download
>   from the mirrors.  No more non-us split.
> 
>   One problem with this might be legal concerns on the part of those
>   U.S. mirrors that someone located outside the U.S. would download
>   from them, and that might be seen as their "exporting" the material.
>   If that's a concern, the mirror could choose not to mirror the
>   crypto packages.  There's probably few enough of those packages
>   that they could be removed by manual admin.

Following up on a same-thread message, joost@rulcmc.leidenuniv.nl said:

> > 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].

It occurs to me that one very good reason for separating out the
non-us stuff is so as not to make it difficult for U.S.-based
CD manufacturers to download a U.S.-exportable Official Debian
Distribution.

In a related vein, Joost goes on to say:

> 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.

That's a good point.  It could happen.  Even if it doesn't, it
seems very U.S.-centric of us to structure the worldwide Debian 
ftp facilities around some wierd and much-derided legal restrictions
applicable only in the U.S.

I'd like to suggest the following approach.  I think that it
provides a pretty clean way of structuring the packages in
a consistent manner on all the sites (wherever located), and
for providing easily-downloadable directory trees containing
trimmed-down package selections (without the non-free packages, or
without non-free+non-us, or without non-free+non-dutch, or without
whatever categories of packages the distribution-structurers feel
are deserving of special provision to make them easily excludable.
It also seems like it would not involve a lot of work or disruption.

1.  Primary ftp site is outside the U.S., in a place where export
    restrictions are not an issue.  This site supports mirrors,
    which in turn support other mirrors.  The mirrors may be
    located anywhere.  The primary site and the mirrors may also
    support individual downloaders.

2.  There are one or more upload sites, located conveniently.
    These sites provide Incoming locations, do any verification
    and pre-processing of uploaded packages which is needed
    (including auto-compile, when that's ready for prime time),
    and upload packages to the primary site to be placed in
    the distribution.  All or most of this would be automated.
    All these sites should use a common version-numbered  set of
    scripts to do the automation.  (the scripts probably ought
    to be distributed in a dqebian package, and maintained just
    like any other debian package)

    Alternatively, the upload sites could feed the primary site
    with raw, unchecked, uploaded packages.  The primary site
    would then do the pre-processing and auto-compiling.  This
    has the advantage of assuring that the pre-processing is
    not done differently at different Incoming sites.  For
    auto-compile, the primary site could upload verified and
    pre-processed incoming source packages to auto-compile
    sites (one per architecture?), and get compiled binary
    packages back from them.

3.  Procedures for deleting packages from the primary site would
    need to be worked out.  Perhaps a special package release
    with a "Delete-Package" keyword in the control file, for
    auto-processing at the primary site.

4.  Package control files would contain a new required
    "Distribution" field.  This field specifies a distribution name
    ("bo", "hamm"; or possibly debian-1.3, debian-2.0).  This field
    must correspond to an existing directory tree name (or symlink
    to one) on the primary ftp site.  This field would be required
    for uploads done after this procedure goes into effect (actually,
    it'd be required for uploads in the pipeline at that time).

5.  Package control files could contain a new optional field
    which may specify one or more "areas".  These might be named
    "main", "non-free", "contrib", "non-us", "non-dutch", etc
    (specifying "main" would be optional, and the field could be omitted).
    This field would designate any special "areas" this package
    belonged in.

    Incidentally, "non-us" and "non-dutch" are bad names.
    These are packages not exportable from those places.  "noex-us"
    and "noex-dutch" would be better.

    A package could be both "contrib" and "noex-us" (that might
    be a crippleware crypto package).  Packages would declare all the
    "areas" where they fit.

5.  All (__all__) packages are placed in one single tree,  containing
    all (__all__) packages which are available for distribution.
    One such tree might be named something like hamm/packages.

6.  A tree of symlinks, possibly named "hamm/main" might contain
    links to all the available hamm packages which do not declare an
    "area" other than "main".  This would be the Official Debian
    Distribution.  It would exclude noex-us, noex-dutch, contrib,
    non-free, and/or any other excludable "areas" which are not
    desired in the Official Debian Distribution.

    Another tree of symlinks, possibly named "hamm/main+contrib+noex-us",
    might contain links to all the hamm "main" packages, plus all the
    packages which declare that they're "contrib" and/or "noex-us".

    Another tree of symlinks, possibly named "hamm/main+contrib",
    [.... well, you get the idea ...]

This seems pretty clean to me.  It would rely on lots of symlinks,
but the symlinks are easy to place and easy to audit by automated
stripts working off the optional "area" fields in the packages.

I see the following (weak) objections to this:

1.  It would require arranging for a primary ftp site with good
    stability, good connectivity, lots of space, and a willingness
    to host Debian, which is located outside the U.S.

2.  It would require some work and reorganization of uploading and
    mirroring.  (not much, though; or so it seems to me)

3.  contrib, non-free and non-us (or noex-us) packages would
    have to be updated to put the new "Area" field in their control files.
    Packages would have to start providing the "Distribution"
    fields on new uploads, but already-uploaded packages 
    needn't be updated to add it. (not a lot of work)

4.  There might be some objection to locating the primary ftp site
    outside the U.S.  (if so, objectors should provide sound
    arguments to back up the objections)

5.  There might be some objection that this scheme doesn't
    sufficiently penalize DFSG violators.  (They'd have "Area: non-free"
    in their control file, and it would be easy to download package
    trees which exclude them, but they'd not be segregated off
    by themselves.)

6.  Some U.S.-based ftp sites might have concern about making the
    non-exportable crypto packages available on their sites.  Ditto
    some dutch sites for the noex-dutch stuff.  If they do, they
    could delete those packages from the "packages" trees.  We might
    make this easy to do by providing noex-us and noex-dutch symlink
    trees pointing to the files to be deleted.  (better, though,
    for the ftp sites with the concerns to change the package
    file permissions so they're unreadable rather than deleting them)

Comments?  Am I saying anything useful, or just making noise?



--
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: