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

Re: software depending on non-US (was: Re: Hey! Why does everybody love flaming so much? [was: `pure'])



On Sat, May 08, 1999 at 02:26:44PM -0500, Manoj Srivastava wrote:
>  Marco> I'm opening a bug against the policy and I propose that those words in
>  Marco> 2.1.3:
> 
>  Marco> "non-free", or "non-US"
>  Marco> be replaced by the words
>  Marco> or "non-free"
> 
>         I think I tend to agree. Could some one please have a look at
>  the non-US licences, and determine which should be non-US/main and
>  which should be non-US/non-free?

We're waiting on a working non-us first.  Wichert says pandora will be
running RSN.


>         What changes would be required in the archive structure of
>  non-US to support non-US/{potato,slink,NEWCODE}/{main,contrib,non-free}/
>  packages? Can apt handle such a restructuring?

(A small portion of) what I currently have is:

deb http://saens.debian.org/debian potato main contrib non-free
deb http://sunsite.doc.ic.ac.uk/packages/Linux/debian-non-US slink/non-US/binary-i386/
deb http://sunsite.doc.ic.ac.uk/packages/Linux/debian-non-US potato/non-US/binary-i386/


When pandora is done and things WORK right again, hopefully I'll be okay
with:

deb http://saens.debian.org/debian potato main contrib non-free
deb http://pandora.debian.org/debian-non-US potato main contrib non-free


At that point the policy change would be safe.  It's not a matter of if
this happens, but when.  And Wichert is guessing when is soon.  So it's
safe to start working out how to do things.


>         We shall also have to modify the non-US upload procedures
>  before this happens.

Do we consider things like libgif3g candidates for non-us/main?  That's
currently sitting on NON-FREE because of the stupid patent on lzw!  IMO
that's just like wrong or something.  =>


>         How many packages in non-US can be moved to non-US/main? How
>  many go to non-US/contrib and non-US/non-free?
> 
>         How many packages in contrib shall be affected? 

A number of them, not sure what that number is, but it's more than
perhaps a couple.  For one thing, the keyring would be able to go into
either non-us/main (or if we decide it's acceptable, main itself) because
gpg can now read both gpg and pgp keyrings freely.  (With of course the
nasty little restriction that the modules which are required to make it
read pgp keyrings aren't non-free but are limited by patents which we
long ago agreed didn't make something non-free..)

If it will help I can compile a listing based on packages I have
installed here.


>         I think we can vote on this proposal in more confidence if
>  these things were known.

Probably.

--
Joseph Carter <knghtbrd@debian.org>            Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBE            The Source Comes First!
-------------------------------------------------------------------------
* Simunye is so happy she has her mothers gene's
<Dellaran> you better give them back before she misses them!

Attachment: pgp4I1sQwqukq.pgp
Description: PGP signature


Reply to: