Quoting "Darren O. Benham" <[EMAIL PROTECTED]>: > On Fri, Jun 04, 1999 at 06:46:47PM -0400, Fabien Ninoles wrote: > > > The data section would be governed by the following rules: > > > - No package can depend on a package in data. > >=20 > > Can *solely* depends on a package in data. ORed Depends, if > > it's also resolved by a default package in main, is good > > in my opinion. Example: A default E-Theme (like icE) in main and=20 > > other theme (like ShinyMetal) in data. > I know you said solely originally, and I removed it on purpose. If Package > Foobar in main *depends* on Package barfoo in data.. then data MUST be > included on the CD or it's useless. Just like contrib is useless w/o > downloading something from non-free. (You can tell what I think of contrib > CDs). Even if Package Foobar could be used with the small data Package BF > which is in main (and depends on both). The fact that it depends on > something in Data means data must be present or you'll get an "unmet > dependencies" error message at install time.
I'm not sure if we agree or not together but I things we need some clarifications: * I think we should follow the same rule as with section and contrib: anything that depends solely (I mean, has no other alternatives) on a package in data, should be also in data. As explain above, the goals is too allow something like this: Package: enlightenment Depends: (...), enlightenement-theme-shiny-metal | enlightenment-theme-ice | ... And having both enlightenment and enlightenment-theme-ice in main, and enlightenment-theme-shiny-metal in data. > > >=20 > > > - No package with an executable can go into data unless it is useable > O= > NLY > > > with a dataset in data. > >=20 > > We should add here that's not the recommend way. This kind of package > > should go in main. Exception can be made for exceptionnaly big data > > packages that impossible to shrink or to provide a default useable data > > set. This way, people can try it on the small archive, then used it if > > they like it. > That would be a way around it. If this is tied to above, the binary could > then Suggest or even Recommend the package in data but not depend on it. A > package with an unmet dependency won't install w/o manual override. That's no the goal of my comments (I really hope to improve my english anytime soon ;). I want to clarify that data is there for commodity. We should not say that any data-oriented packages should go in data. Only packages that are so big that they tends to blow main too much for little mirrors and CD vendors. > > >=20 > > > - The maintainer decision on this subject is just the same as with the > > > Section: field. It's a suggestion that can be override by the archive > > > maintainer. > > > - Only DFSG free datasets are alowed in data. There is no non-free > sec= > tion > > > of data and contrib does not make sense when applied to datasets. To > > > that end, datasets can not depend on anything in contrib or non-free. > > > - Datasets that currently have no DFSG-free viewer are still DFSG-free > = > if > > > the license to that data is DFSG-free. > > Hum... We should add they most not depends on the viewer. Contrib are for > > those type of data, IMHO. But I don't care; If people can find data they > > can't view useful... > (to finish) let them build the viewer. I agree. But then, depending on > something in contrib or non-free would make it non-main and the data > section is only a "main" type section. There is no data/contrib or > data/non-free. That's what I mean. I just think we should make this point clear. > * http://benham.net/index.html <[EMAIL PROTECTED]> <>< * > * -------------------- * -----------------------------------------------* > * Debian Developer, Debian Project Secretary, Debian Webmaster * > * <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> * > * <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> * So, I mustly agree with you're proposal. It's only I want to make it clear (Hopefully, my reading skills is better than my writing one). ------------------------------------------------------------------------ Fabien Ninoles Chevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Debian GNU/Linux maintainer E-mail: [EMAIL PROTECTED] WebPage: http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 ------------------------------------------------------------------------
