Re: RFC: new policy on dependencies between distributions (was Re: need decision on packages with crypto hooks)
On Sat, 29 Mar 1997, Andreas Jellinghaus wrote:
> Christian Schwarz wrote:
> ...
> > The rules:
> >
> > o Every package in the free (main) distribution may only Depend or
> > Recommend packages in the free distribution.
> >
> > o Every package in the non-free distribution may only Depend or Recommend
> > packages in the main or non-free distribution.
> >
> > o Every package in the non-us distribution may only Depend or Recommend
> > packages in the main or non-us distribution.
> >
> > o Any other package has to go into the contrib distribution.
>
> by current policy a program goes into non-free, if it's policy doesn't
> permit to put it on cdrom. even if it depends on a contrib program, you
> still have to put it in non-free. that's because you can put contrib on
> a cd-rom, but not non-free.
No, that's not right. There are "contrib" packages that have some
copyright restrictions (koules, picasm, etc.) that you can't put on a
CD-ROM. And according to the current Policy Manual, section 2.3 states
that "Packages which depend for their use on non-free or contrib packages
may only be placed in the semi-supported contrib section".
> if a program is in non-us, but requires a non-free program, you may
> still not put it into contrib, because of it's non-us status.
Right. I thought that the license question has priority over the above
dependency rule. Was this unclear?
> you can, of course proced as above, but spliting contrib into 3 parts:
> contrib, contrib/non-free and contrib/non-us. (or spliting non-free and
> non-us in the non-free respective non-us part and a non-free/contrib
> respective non-us/contrib part).
I thought that "contrib/non-free" actually is "contrib" (as far as I
understood the policy, everything that is not "free" nor "non-free" is
"contrib" with the possible exception of "non-us") and that
"contrib/non-us" is "non-us".
That's another point: non-us doesn't have a stable/unstable seperation.
> > o Every package may Suggest or Conflict with any other package, no matter
> > in which distribution they are.
> >
> >
> > Examples (can be used as references):
> >
> > o A free package depending on a non-free package has to go to contrib.
> >
> > o A free or non-free package depending on a non-us package has to go to
> > contrib. For example the crpyto-hook package "pinepgp" is free (GPL) but
> > certainly depends on PGP, so it has to go into contrib.
>
> a non-free package goin into contrib ? that's a) violates current policy
> and b) a cdrom vendor cannot put contrib on cdrom. as far as i know,
> current contrib can included in a cdrom (all packages, that may not
> included in a cdrom are in non-free).
We differ here. What's the opinion of the others?
Actually I _am_ a cdrom vendor so I had a look which packages I could
include. I checked all licenses in the non-free and contrib section and
decided _not_ to include three packages out of contrib: ferret (no license
included), koules, and picasm.
> > Any comments?
>
> a package has
> a) a distribution : stable/ unstable/ tested
> b) a cdrom-marker : free / non-free
> c) a contrib-marker : free / contrib (only for free packages)
> d) a crypt-marker : ok-in-us / non-us
> f) a depends-marker : normal / "depends" (package depends/requires
> something not in his distribution or in the free distribution).
>
> i don't know, how to solve this problem, but it's not simple.
> at least: don't put something that is "non-free" or "non-us" into
> contrib, even if it depends on a "contrib" program".
That's a very systematic approach which is perhaps too complicated for our
situation. Consider that there are only 8 packages in non-us.
> > I would like to add something like this to the Policy Manual.
> >
>
> o Every package in the free (main) distribution may only Depend or
> Recommend packages in the free distribution.
>
> o If a package is non-free (see policy) it has to go into non-free.
> (yes, it may depend/recommend a package in contrib).
>
> o If a package is non-us (see policy) it has to go into non-us.
> (yes, it may depend/recommend a package in contrib).
>
> o Any other package has to go into the contrib distribution.
To summerize: I used the following order of distributions:
free
non-free / non-us
contrib
where you prefer the order
free
non-free / contrib / non-us
> this will result in :
>
> - packages in non-free might depend on contrib programs.
> - packages in non-us might depend on contrib programs.
> - packages in contrib might depend on contrib programs.
>
> yes, this is the current situation, and it causes trouble, but the other
> alternative i see, is to use 5 markers for
> - distribution
> - cdrom-status
> - crypto-status
> - contrib-status
> - depends-status
>
> currently we have a bix mix (unstable/stable/frozen/non-free/contrib/non-us).
> "contrib" says nothing about stability, "non-free" says nothing about
> depending on a contrib program or not etc.
>
> restrictions:
> a program will never by "non-free" and "non-us" (i hope).
> we don't distinguish between unstable,stable,tested for non-us programs.
>
> so we have to move from one marker to 3 markers. this will result in
> method a) method b)
> unstable free/official/unstable
> stable free/official/stable
> tested free/official/tested
> contrib/unstable free/contrib/unstable
> contrib/stable free/contrib/stable
> contrib/tested free/contrib/tested
> non-free/unstable non-free/official/unstable
> non-free/stable non-free/official/stable
> non-free/tested non-free/official/tested
> non-free/contrib/unstable non-free/contrib/unstable
> non-free/contrib/stable non-free/contrib/stable
> non-free/contrib/tested non-free/contrib/tested
> non-us non-us/official
> non-us/contrib non-us/contrib
>
> it might take some work, but improving our current system with only one
> marker for everything is importend (IMO).
This just makes it more complicated. What about mixing non-free and
contrib? (Hope this brave question doesn't start a flamewar :-)
Cheers,
Chris
-- _,, Christian Schwarz
/ o \__ schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
! ___; schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
\ /
\\\______/ ! PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
\ / http://fatman.mathematik.tu-muenchen.de/~schwarz/
-.-.,---,-,-..---,-,-.,----.-.-
"DIE ENTE BLEIBT DRAUSSEN!"
Reply to: