Re: Let's CENSOR it!
fpolacco@icenet.fi (Fabrizio Polacco) wrote on 18.03.99 in <[🔎] 19990318161217.G24730@none>:
> On Thu, Mar 18, 1999 at 09:43:41AM +0000, Enrique Zanardi wrote:
> >
> > One step in that direction would be to create some rules for "extra"
> > sections. Let's take electronic texts as an example for such an "extra"
> > section:
> >
> > - We create an "etexts" section.
> > - text-only (or mostly-text) packages, not related to any program on the
> > distribution (that means I'm not talking about glibc-doc here...)
> > should go there.
> > - "program" packages related to those text-only packages should go into
> > "etexts" too (that means as bible-kjv-text go there, bible-kjv go there
> > too).
> > - No package from outside the "etexts" section should depend|recommend a
> > package on the "etexts" section (sort of the way a "main" package
> > shouldn't depend|recommend on a "contrib" package).
> >
> > PS: (This idea, or a very similar one, was proposed by Fabrizio Polacco a
> > long time ago).
>
> Exactly I proposed what has been already suggested today by someone
> else, to create a new "part" (not a section inside main) at the same
> level as main/contrib/non-free/non-US and create a separate CD image
> from it (maybe with contrib in it if there are room) which can be
> optionally added to the official CD set.
> I can even imagine to have a separate site for it, if it grows too much.
Exactly.
As for general criteria when to create an extra part:
* If there is a very large package (say, > 10 MB), think about creating an
extra part where it would fit. Or find a *very* good reason to keep it.
* If something has no relation to an OS at all (like generic electronic
texts), think about an extra part where it would fit.
Just for illustration, a list of very large (10 MB+) packages from a
partial mirror:
dists/potato/contrib/binary-all/graphics/picon-usenix_1995.04.13-5.deb
dists/potato/main/binary-i386/devel/cmucl_2.4.9.deb
dists/potato/main/binary-i386/devel/libwine-dbg_0.0.990131-1.deb
dists/potato/main/binary-i386/devel/mercury_0.8.1-1.deb
dists/potato/non-free/binary-all/text/dict-web1913_1.4a-1.deb
dists/slink/contrib/binary-all/graphics/picon-usenix_1995.04.13-4.deb
dists/slink/contrib/binary-i386/misc/iraf-common_2.11.1-1.deb
dists/slink/contrib/binary-i386/misc/iraf-ibin_2.11.1-1.deb
dists/slink/contrib/binary-i386/misc/iraf-noaobin_2.11.1-1.deb
dists/slink/main/binary-all/devel/kernel-source-2.1.125_2.1.125-1.deb
dists/slink/main/binary-all/devel/kernel-source-2.2.1_2.2.1-1.deb
dists/slink/main/binary-all/doc/doc-rfc_1999.01-1.deb
dists/slink/main/binary-all/doc/gimp-manual_1.0.0-1.deb
dists/slink/main/binary-all/editors/xemacs20-support_20.4-13.deb
dists/slink/main/binary-all/sound/timidity-patches_0.1-4.deb
dists/slink/main/binary-all/tex/tetex-src_0.9.980803-1.deb
dists/slink/main/binary-all/x11/xbooks_3.3.2.3a-2.deb
dists/slink/main/binary-i386/devel/cmucl_2.4.8.deb
hamm/hamm/binary-all/editors/xemacs20-support_20.4-5.deb
hamm/hamm/binary-all/sound/timidity-patches_0.1-3.deb
hamm/hamm/binary-all/x11/xbooks_3.3.2.3-2.deb
That's over 1/4 GB right there - and I didn't even look at non-Intel
packages.
MfG Kai
Reply to: