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

Re: Initial Proposal to solve this non-US issue



On Sun, Nov 15, 1998 at 10:30:47PM -0500, Ben Collins wrote:
> First of all, if you don't appreciate this idea, ignore it, don't flame
> me, since no one else can come up with a decent idea, just senseless
> bickering.
> 
> There should be a new layout for the 'restricted' packages. First of all
> non-US is misleading in that it implies that they are restricted simply
> because of the US, which is false. The layout would look something like
> this (simplisticly):
> 
> potato (normal)
>   \main
>     -Packages
>     -Packages.gz
>     \devel
>       -gcc
>       -binutils
>     \base
>       -base-files
>     \x11
>       -xterm
> 
> potato-r (restricted)
>   \main
>     -Packages-r
>     -Packages-r.gz
>     \mail
>       -mutt
>     \misc
>       -package-that-depends-on-libssl-but-otherwise-not-restricted
>       -gpg
>     \libs
>       -libssl

The issue has some problems, namely making it quite hard for someone to
mirror with common software without risking that they may already be
breaking the law by fetching software which is not legal in there area.

I'd suggest something more along the lines of

potato
  \main (normal)
    -Packages
    -Packages.gz
    \devel
      -gcc
      -binutils
    \base
      -base-files
    \x11
      -xterm
  \main-non_us_export
    -Packages
    -Packages.gz
    \misc
      -package-that-depends-on-libssl-but-otherwise-not-restricted
      -gpg
    \libs
      -libssl
  \non-free-non_us_export
    -Packages
    -Packages.gz
    \misc
      -pgp

This has the advantage that this is already in place for non-free
packages, as just another section, now this does have some issues
dealing with files which are in both non_us and non_fr however thats
already handled with binary-all (Tho it may be argued that this is a
poor answer)..


> These two layouts could then be overlayed so that it makes one complete
> distribution that allows for one CD that could be easily made, as well
> mirrors could continue as normal to mirror the unstable/stable/frozen
> dists without worry of downloading the restricted packages. This that
> mirror in a non-restrcited country could then mirror both and merge them
> if desired to create the entire 'restricted' distribution.

The same can be said of mine I do believe..
> 
> dselect would have to be modified to recognize the Package-r files and
> combine it virtually with the main Package.

Not a issue with my suggestion..
> 
> The packages would also need some sort of modifier in the control file to
> denote that it is restricted (ie. 'Restricted: yes') so that the current
> deb ftp scripts can be modified to cope with it easily, and guard against
> maintainers that inadvertently mark their package restricted but upload it
> to a server in a restricted country.

So instead of just getting the directory the mirrors first have to get
the packages file, parse it, and then attempt to mirror just the right
files, both source and binary..

This also has a issue of maintainability, say you a package which is not
allowed in de but is allowed everywhere else, another one which is
not allowed in fr but is everywhere else, etc, until you have no one
country where we can host the master-restricted and still hold all the
files..

As such it may not be the best answer, but then again mine has issues as
well..
> 
> Let's see how many ppl shoot this down before i go to bed tonight :)

And how many shoot this one down before I go to bed.. (=:]

Zephaniah E, Hull.
> 
> -- 
> -----    -- - -------- --------- ----  -------  -----  - - ---   --------
> Ben Collins <b.m.collins@larc.nasa.gov>                  Debian GNU/Linux
> UnixGroup Admin - Jordan Systems Inc.                 bcollins@debian.org
> ------ -- ----- - - -------   ------- -- The Choice of the GNU Generation



-- 
 PGP EA5198D1-Zephaniah E, Hull <warp@whitestar.soark.net>-GPG E65A7801
    Keys available at http://whitestar.soark.net/~warp/public_keys.
           CCs of replies from mailing lists are encouraged.

Attachment: pgpSz5eF1eyZ5.pgp
Description: PGP signature


Reply to: