Re: RFC: new policy on dependencies between distributions (was Re: need decision on packages with crypto hooks)
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.
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.
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).
> 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).
> 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".
> 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.
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).
regards andreas
Reply to: