Re: Status on Proposal for restricted packages
On Thu, Nov 26, 1998 at 09:56:22PM -0600, email@example.com wrote:
> What is the point in creating an incomplete database that contains only the
> common stuff that anyone involved with restricted packages already knows
The point here isn't the restriction types so much as it is the
import/export restrictions. If we are going to lay our mirroring sites
legal issues on the line with this info, it needs to be handled a little
more consistently. If package A and package B are of the same
restrictions, and it is left to the maintainers to decide where that
package can go, it can actually vary, and a mirror ends up with a package
they shouldn't have, or package A and B aren't really kept on all the same
sites. Even worse if package A depends on package B, and they don't have
the same where-to info...
Now on the other hand, if this info were kept centrally, and only the
restriction type was specified, the database would affect all such
packages and keep consistency.
Also, with my proposal it is left up to the maintainer to decide whether
or not to use the standard types, they can easily specify one of their own
and fill in all the info manually without breaking things. I think we need
the option to make life alot easier, not harder.
> Then what is he doing maintaining a restricted package?
Your original message stated it was too difficult for a maintainer to pick
from a list of restriction types, but you said it would be easier for them
to know what the import/export restrictions were. My point was, if it's
too hard to pick out the type, how is he supposed to know the
restrictions? You sort of contradicted yourself.
----- -- - -------- --------- ---- ------- ----- - - --- --------
Ben Collins <firstname.lastname@example.org> Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. email@example.com
------ -- ----- - - ------- ------- -- The Choice of the GNU Generation