[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 Mon, 14 Jul 1997, Lalo Martins wrote:

> Maybe starting with hamm a better categorization could be used. Like:
> 
>   -Non-US    (already exists)
>   -No-profit (can't be sold for profit)
>   -No-sell   (can't be sold even for cost)
>   -Rest-use  (restricted use)*
>   -Stub      (installers - these can always be sold as they're made by us)*

    -Installs  (better name?)
    -Instalrs  (better name?)

>   -Depprobl  (free stuff that depends on non-free stuff, like motif apps)*

    -Dep-prob  (better name?)

> This makes things clearer for admins and CD vendors. Stuff marked with a *
> would go into official CDs.
> 
> Maybe I overdid it, or maybe the names are lamish... but the suggestion is
> open. I really think it's important.

This sounds like a big improvement over "non-free" and "contrib".

Also, I've seen complaints that dselect couldn't handle installing
some areas (contrib?  non-US?).  I think I've also seen complaints
that there were problems uploading non-US packages.  Perhaps it would
be useful to couple a redo of "non-free" and "contrib" with regularization
of the directory structure on ftp sites and their expected locations on
user systems.  Perhaps something like the following:

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

Users (in or out of the U.S.) could retrieve the Non-US stuff
from non-US mirrors.  Upload tools could upload to a non-US
distribution site (from non-US maintainers, but using the same
upload tools they use for mainline packages)

Also, user systems might have a Local directory for packages
not obtained from Debian distribution sites (e.g., locally
built packages), and an Updates directory for packages
updating those on the system's Debian CDROM.  Something like:

On a user's local system:
   /whatever/whatever/
     Debian-X.Y/
       Debian-X.Y --> /cdrom/Debian-X.Y/Debian-X.Y
       Rest-use --> /cdrom/Debian-X.Y/Debian-X.Y/Rest-use
       ...
       Local/
         source/
         binary-i386/
         ...
     Updates/         # downloaded updates, superseding those from cdrom
       Debian-X.Y/
       ...

A useful and meaningful partitioning of packages not in the mainline
distribution.  Consistent location and structuring of subdirs
containing package "areas".  Structuring to accommodate addition
of Local packages on a user system.  Package upload and package
maintenance tools usable for all package "areas".  Friendly to
the addition/deletion of package "areas".  Able to deal with
a Debian CDROM supplemented by selectively-downloaded update
packages.

This is off the top of my head, and could no doubt stand improvement.



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