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

Re: Non-free, Contrib and CDs (Was Re: GNU Win32? Not anymore.)



On Thu, 17 Jul 1997, Lalo Martins wrote:

> On Jul 16, Bill Mitchell wrote
> > On Mon, 14 Jul 1997, Lalo Martins wrote:
> > 
> > >   -Depprobl  (free stuff that depends on non-free stuff, like motif apps)*
> > 
> >     -Dep-prob  (better name?)
> 
> No, sounds like it probes something. Maybe "depend-p"?

I never have been very good at choosing names, though I recognize
the importance of choosing good ones.  Let me take another go at
the list:

  Name             CD?    Criteria
  ----             ---    --------
  Main             Yes    Mainline Debian distribution
                          Social Contract compatible
  No-Export        No     US Export Restricted
  No-Profit        No     Cannot be sold for profit
  No-Sell          No     Cannot be sold, even for cost
  Use-Restricted   Yes    Usage is restricted
                          but can be sold for profit
  Installers       Yes    Installers
  Depends-Problem  Yes?   Depends on package in No-* areas

Note:  The "CD?" column would be for the "Official Debian CD".  Other
       CDs based on Debian material would, of course, make their own
       determinations about this.

Note:  On CDs used under MSDOS, these names would probably be truncated
       to the first eight chars and single-cased.
[...]
> > On a Debian FTP site or mirror (US and Non-US):
> >     Debian-X.Y --> codename
> >     codename/
> >       Debian-X.Y/     # main distribution
> >       Non-US/         # would be empty, or README only, in U.S.
> >       No-profit/      # no resale for profit
> >       ...             # the rest of the stuff from above
> > 
> > The subdirs below codename/ would all have a consistent structure
> > (source, doc, binary-{arch}, etc).
> 
[...]
> Not exactly. Debian-X.Y/*/ are still split into sections, while others have
> packages directly. What about: (for ftp, CDs, user's local systems alike)
[... suggestion moves Non-US, etc. under the second Debian-X.Y...]
> This can make it hard to burn non-official CDs, I don't know - but it's
> consistent, and consistence is one of the reasons I use Debian in the first
> place.

I think it's important for CD manufacturers to be able to easily
exclude the stuff which gives them distribution problems by making
choices at a high level in the directory tree.  Also, I think you
and I are both glossing over some necessary detail in our directory
tree summaries.  Let me take another go at this:

Current structure at ftp.debian.org:

  .../pub/debian
    rex/
    bo/
    contrib/
    non-free/
    {other stuff}
    hamm/
    | main -> hamm
    | hamm/
    | | binary -> binary-i386
    | | binary-{arch}/           # binary-i386, etc.
    | | | {section-name}/        # admin, base, ...
    | | |    {package.deb files, or symlinks to them}
    | | source/
    | | | {section-name}/        # admin, base, ...
    | | |    {package source files, or symlinks to them}
    | | disks-{arch}/            # install disk images, etc
    | contrib/
    | | binary -> binary-i386
    | | binary-{arch}/           # binary-i386, etc.
    | | | {section-name}/        # admin, base, ...
    | | |    {package.deb files, or symlinks to them}
    | | source/
    | | | {section-name}/        # admin, base, ...
    | | |    {package source files, or symlinks to them}
    | non-free/
    | | binary -> binary-i386
    | | binary-{arch}/           # binary-i386, etc.
    | | | {section-name}/        # admin, base, ...
    | | |    {package.deb files, or symlinks to them}
    | | source/
    | | | {section-name}/        # admin, base, ...
    | | |    {package source files, or symlinks to them}
    | msdos-i386/              # (not in hamm yet, this is from bo)
    | |   {msdos-section-name}/  # admin, base, ... (some abbrvtd)
    | |      {symlinks to package.deb files}  # some names abbrvtd

I note that the rex and bo trees have empty non-free and contrib
directories.  I also note that there are populated contrib and
non-free directories at the pub/debian level, alongside rex,
bo, and hamm.  These populated contrib and non-free trees
are not organized by section (admin, base, ...), and it's not
clear to me whether the binaries contained therein are compiled
for rex, bo, or hamm. (or, in fact, whether they're compiled
consistently for any one of these) 

However, with the (currently unpopulated) contrib and non-free
directories in the hamm tree, and except for the msdos-i386 tree,
the structure is quite regular.  Perhaps msdos-i386 should change
to simply msdos, and have binary-i386 and binary-all directories
under it.  That would bring its structure into conformity with
the structure of its siblings.

What I'd advocate is retaining the regularity, but splitting up the
current non-free and contrib trees in hamm into several new trees
with different names and criteria for package inclusion, as outlined
above for No-Profit, etc.

CD manufacturers not wishing to go to the bother of dealing with
copyright restrictions on a package-by-package basis by contacting
individual package copyright holders for permission to distribute
could exclude distribution-restricted packages by simply not picking
up the No-profit and No-sell trees.

We could make that even easier for them by renaming hamm/hamm to be
hamm/hamm-full and by having a hamm-free tree alongside the hamm-full
tree.  The hamm-free tree would have symlinks into the hamm-full tree,
except that the No-Profit and No-Sell links (and No-Export on US sites)
would be missing, stubbed out, or pointed to README files explaining
the restrictions which led to their exclusion.  We might also have
a hamm-strict tree, which would exclude the Use-Restricted and
Depends-Problem trees on the grounds of not strictly respecting the
Debian Social Contract (though I can't think of why anyone would
choose to pick up that directory over the other hamm-* directories).

Finally, it occurs to me to wonder if debian-devel is the best place
to discuss this.  These are pretty fundamental issues, and changes 
would impact the project at a pretty high level.  There needs to
be consensus on how difficult we want to make it for people to get
hold of packages which don't conform to our Social Contract.  There
would need to be some FTP site reorganization, with consequent changes
in admin procedures.  There'd also need to be a new package control
file field (Possibly named "Area:", probably optional and defaulted to
"Main").  There would probably be other impacts as well.   Perhaps a
debian-devel discussion of these issues will be nonproductive, or
even counterproductive, and the discussion should be moved to
debian-private (where I'm not currently subscribed).



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