[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#38902: PROPOSED] data section



Quoting "Darren O. Benham" <gecko@debian.org>:

> 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        <gecko@benham.net>           <><  *
> * -------------------- * -----------------------------------------------*
> * Debian Developer, Debian Project Secretary, Debian Webmaster          *
> * <gecko@debian.org> <secretary@debian.org> <lintian-maint@debian.org>  *
> * <webmaster@debian.org> <gecko@fortunet.com> <webmaster@spi-inc.org>   *

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:                                                    fab@tzone.org
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
------------------------------------------------------------------------


Reply to: