Debian Bug report logs - #38902
[Sections] Please add a "data" section

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

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

To: submit@bugs.debian.org

Subject: [PROPOSED] data section

Date: Thu, 3 Jun 1999 15:29:08 -0700

Package: debian-policy
Severity: wishlist

This is Fabian's proposal with a few modifications.  The last proposal was
not put into the BTS and then there was talk of waiting for Wichert's
proposal.  I've talked with our DPL and he doesn't have one.. not on this
topic.  So.. here it is again and formally proposed according to Manoj's
scheme.

Some of this text comes from an email I received from Richard Kreckel.

Since there is interest in packaging census data, maps, genome data
and other huge datasets I and since most people agreed that dropping them 
in main or contrib is not a great idea, I propose the creation of a data
section to reside along side of main, contrib and non-free.

The data section would be governed by the following rules:
- No package can depend on a package in data.
- No package with an executable can go into data unless it is useable ONLY
  with a dataset in data.
- 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 section
  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.

reason:
- The data subdirectory is an entire part of Debian. Its purpose is to
  let the CD vendors/archives maintainers/users choice between a Debian
  Light who fit on a reasonable amount of CDs, and an Debian Extended who
  can fill your entire RAID array.

-- 
Please cc all mailing list replies to me, also.
=========================================================================
* 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>   *
=========================================================================

Message #10 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Steve Greenland <stevegr@debian.org>

To: 38902@bugs.debian.org

Subject: Re: Bug#38902: [PROPOSED] data section

Date: Thu, 3 Jun 1999 19:33:03 -0500

A few additional rules for your consideration:

- The data directory shouldn't be synced to debian releases, and ought
  to be paralled to dists, not main/contrib/non-free.
  (Since there are no executables, what's the benefit of syncing it, with
   the presumed multiplying of size and hassle? If a dataset needs a particular
   program or version, a simple dependency should be enough.)

A thought: Do we need to keep a source archive separate from the .deb?
Almost all of these package are effectively their own source, and since
we are talking about large datasets, the burden of keeping both seems
unnecessary. Before you light up the flamethrower, I'm not promoting the
idea of not releasing source. But consider a package that is basically
a reproduction of a website. Do we really need two 7Mb packages who's
fundamental difference is that they unpack into a different location?
Instead, we could make the .debs act like installers, except that
they would grab the external archive from the CD or via http. Or have
a /usr/doc/<package>/debian, whose rules file has a way to copy the
installed data into a new tree in order to rebuild the package.

Steve

Message #15 received at 38902@bugs.debian.org (full text, mbox, reply):

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

To: Steve Greenland <stevegr@debian.org>, 38902@bugs.debian.orgy

Subject: Re: Bug#38902: PROPOSED] data section

Date: Thu, 3 Jun 1999 20:11:07 -0700

On Thu, Jun 03, 1999 at 07:33:03PM -0500, Steve Greenland wrote:
> A few additional rules for your consideration:
> 
> - The data directory shouldn't be synced to debian releases, and ought
>   to be paralled to dists, not main/contrib/non-free.
>   (Since there are no executables, what's the benefit of syncing it, with
>    the presumed multiplying of size and hassle? If a dataset needs a particular
>    program or version, a simple dependency should be enough.)
I thought about this... but in the case of a format change, a reader would
have to be downloaded out of unstable (if you have a stable dist) or the
data would have to wait until unstable is stablized.  If there is no change
in the data, then symlinks should suffice to not create a duplicate of
data.  Espcially if they DON'T change very often.

> A thought: Do we need to keep a source archive separate from the .deb?
> Almost all of these package are effectively their own source, and since
> we are talking about large datasets, the burden of keeping both seems
> unnecessary. Before you light up the flamethrower, I'm not promoting the
> idea of not releasing source. But consider a package that is basically
> a reproduction of a website. Do we really need two 7Mb packages who's
> fundamental difference is that they unpack into a different location?
> Instead, we could make the .debs act like installers, except that
> they would grab the external archive from the CD or via http. Or have
> a /usr/doc/<package>/debian, whose rules file has a way to copy the
> installed data into a new tree in order to rebuild the package.
Very good point.   From what I understand, ammendments to proposals should
be "convince the proposer" so if you agree with this, steve, consider me
convinced to amend as follows:

- Data debs should include all files from the original, upstream source
  installed into proper directories for Debian's requirements.  So being,
  a seperate source archive need not be kept.
> 
> Steve
> 
> 
> --  
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

-- 
Please cc all mailing list replies to me, also.
=========================================================================
* 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>   *
=========================================================================

Message #20 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Edward Betts <edward@debian.org>

To: 38902@bugs.debian.org

Subject: Re: Bug#38902: [PROPOSED] data section

Date: Fri, 4 Jun 1999 09:27:57 +0100

On Bug #38902, "Darren O. Benham" <gecko@debian.org> wrote:
> The data section would be governed by the following rules:
> - No package can depend on a package in data.

Where does that leave bible-kjv, bible-kjv-text and verse?

Can a package in main recommend a package in data?

> - No package with an executable can go into data unless it is useable ONLY
>   with a dataset in data.

So should bible-kjv be moved to data as well? What about verse?

>- Only DFSG free datasets are alowed in data.  There is no non-free section
>  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.

So what about dict-web1913? it is the most complete dictionary for dictd but
it is non-free. Does that mean that it stays in non-free, does it mean that it
is erases, or does the proposal need changing. Also I thought the DFSG could
not be applied to documents because they are not program, which is why Perl is
allowed to include the Perl FAQ.

What kind of packages are we thinking of for data?

Web mirrors?
anarchism - An exhaustive exploration of Anarchist theory and practice.
gimp-manual - Manual for the GNU Image Manipulation Program
gnu-philosophy - Philosophy of the GNU Project
jargon-html - The definitive compendium of hacker slang.

Funny manpages?
asr-manpages - alt.sysadmin.recovery manual pages
funny-manpages - more funny manpages

Magazine back issues?
heise-register - register of the magazines c't, iX, Elrad and Gateway
lg-base - Shared files for the Linux Gazette.
lg-issue01to08 - Issues 1 to 8 of the Linux Gazette.
lg-issue* - Issue * of the Linux Gazette.
pj-* - * * number of Pluto Journal.

Technical documents?
bible-kjv-text - King James Version of the Bible - text and concordance
doc-rfc - Important RFCs

Dictionaries?
dict-easton - Easton's 1897 Bible Dictionary
dict-elements - Data regarding the Elements
dict-foldoc - FOLDOC Dictionary Database
dict-gazetteer - U.S. Gazetteer
dict-hitchcock - Hitchcock's Bible Names Dictionary
dict-jargon - Jargon File 4.0.0
dict-wn - WordNet v1.6
dict-web1913 - 1913 Webster's Dictionary
miscfiles - Dictionaries and other interesting files.

-- 
I consume, therefore I am

Message #25 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Branden Robinson <branden@ecn.purdue.edu>

To: 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Fri, 4 Jun 1999 10:34:11 -0400

[Message part 1 (text/plain, inline)]

On Fri, Jun 04, 1999 at 09:27:57AM +0100, Edward Betts wrote:
> What kind of packages are we thinking of for data?
> 
> Web mirrors?
> anarchism - An exhaustive exploration of Anarchist theory and practice.
> gimp-manual - Manual for the GNU Image Manipulation Program
> gnu-philosophy - Philosophy of the GNU Project
> jargon-html - The definitive compendium of hacker slang.
> 
> Funny manpages?
> asr-manpages - alt.sysadmin.recovery manual pages
> funny-manpages - more funny manpages
> 
> Magazine back issues?
> heise-register - register of the magazines c't, iX, Elrad and Gateway
> lg-base - Shared files for the Linux Gazette.
> lg-issue01to08 - Issues 1 to 8 of the Linux Gazette.
> lg-issue* - Issue * of the Linux Gazette.
> pj-* - * * number of Pluto Journal.
> 
> Technical documents?
> bible-kjv-text - King James Version of the Bible - text and concordance
> doc-rfc - Important RFCs
> 
> Dictionaries?
> dict-easton - Easton's 1897 Bible Dictionary
> dict-elements - Data regarding the Elements
> dict-foldoc - FOLDOC Dictionary Database
> dict-gazetteer - U.S. Gazetteer
> dict-hitchcock - Hitchcock's Bible Names Dictionary
> dict-jargon - Jargon File 4.0.0
> dict-wn - WordNet v1.6
> dict-web1913 - 1913 Webster's Dictionary
> miscfiles - Dictionaries and other interesting files.

I wouldn't mind seeing all of these move into the data section.

There's no point having a data section if we're not going to be consistent
about how we use it, and if we're not going to try very, very hard to keep
our criteria objective (i.e., no arguments like "the Jargon file can stay
but the Bible has to go").

I don't really regard bible-kjv-text as a technical document, but... :)

If I understood the proposal correctly, bible-kjv and verse would both go
into the new data section.  "verse" because it's designed to work only with
only one data file -- bible-kjv.

-- 
G. Branden Robinson              |   A celibate clergy is an especially good
Debian GNU/Linux                 |   idea, because it tends to suppress any
branden@ecn.purdue.edu           |   hereditary propensity toward fanaticism.
cartoon.ecn.purdue.edu/~branden/ |   -- Carl Sagan

[Message part 2 (application/pgp-signature, inline)]

Message #30 received at 38902@bugs.debian.org (full text, mbox, reply):

From: "Oliver Elphick" <olly@lfix.co.uk>

To: Branden Robinson <branden@ecn.purdue.edu>, 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Fri, 04 Jun 1999 16:29:26 +0100

Branden Robinson wrote:
  >I don't really regard bible-kjv-text as a technical document, but... :)
  
It's a manual -- for living.

  >If I understood the proposal correctly, bible-kjv and verse would both go
  >into the new data section.  "verse" because it's designed to work only with
  >only one data file -- bible-kjv.
                         
bible-kjv-text is the data, bible-kjv the program.

bible-kjv could theoretically handle any text in the same way as the bible,
but no other text has been formatted for it to work on.

verse doesn't use bible-kjv-text for its source, but a compilation of
quotes that its original author put together.  It is actually a rather
small package, with a 38Kb deb, including the verses.  It's on a par
with, say, fortune.  I don't think it really fits the purpose of data.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "But without faith it is impossible to please him; for 
      he that cometh to God must believe that he is, and 
      that he is a rewarder of them that diligently seek 
      him."       Hebrews 11:6 

Message #35 received at 38902@bugs.debian.org (full text, mbox, reply):

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

To: Edward Betts <edward@debian.org>, 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Fri, 4 Jun 1999 09:56:47 -0700

[Message part 1 (text/plain, inline)]

On Fri, Jun 04, 1999 at 09:27:57AM +0100, Edward Betts wrote:
> Where does that leave bible-kjv, bible-kjv-text and verse?
Personally, I view them as part of the bible and verse program... the
second point should be able to make each case subjective.. 

> 
> Can a package in main recommend a package in data?
Yes.  recommends: (and suggests:) != depends:
> 
> > - No package with an executable can go into data unless it is useable ONLY
> >   with a dataset in data.
> 
> So should bible-kjv be moved to data as well? What about verse?
Subjective... what do you think?

> >- Only DFSG free datasets are alowed in data.  There is no non-free section
> >  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.
> 
> So what about dict-web1913? it is the most complete dictionary for dictd but
> it is non-free. Does that mean that it stays in non-free, does it mean that it
> is erases, or does the proposal need changing. Also I thought the DFSG could
Stays in non-free.  This proposal doesn't state that data can not be in any
other section.

> not be applied to documents because they are not program, which is why Perl is
> allowed to include the Perl FAQ.
Really?  Where and to what the DFSG is applied to varies with who you talk
to... from what I can tell.  I think the only thing that the DFSG isn't
being unilatterally(sp?) applied to is documentation that accompanies a
DFSG-free binary (script).


> What kind of packages are we thinking of for data?
> 
> Web mirrors?
> anarchism - An exhaustive exploration of Anarchist theory and practice.
This is part of what started it..

> gimp-manual - Manual for the GNU Image Manipulation Program
This is documentation to a program included, (subjective but) I would not
move it.

> gnu-philosophy - Philosophy of the GNU Project
Moveable... this has had the same complaints as the anarchism.

> jargon-html - The definitive compendium of hacker slang.
subjective..

> 
> Funny manpages?
> asr-manpages - alt.sysadmin.recovery manual pages
> funny-manpages - more funny manpages
> 
> Magazine back issues?
Moveable...

> heise-register - register of the magazines c't, iX, Elrad and Gateway
> lg-base - Shared files for the Linux Gazette.
> lg-issue01to08 - Issues 1 to 8 of the Linux Gazette.
> lg-issue* - Issue * of the Linux Gazette.
> pj-* - * * number of Pluto Journal.
> 
> Technical documents?
I wouldn't move them unless the size is "objectionable"
> bible-kjv-text - King James Version of the Bible - text and concordance
> doc-rfc - Important RFCs
> 
> Dictionaries?
I wouldn't but I don't know much about them..

> dict-easton - Easton's 1897 Bible Dictionary
> dict-elements - Data regarding the Elements
> dict-foldoc - FOLDOC Dictionary Database
> dict-gazetteer - U.S. Gazetteer
> dict-hitchcock - Hitchcock's Bible Names Dictionary
> dict-jargon - Jargon File 4.0.0
> dict-wn - WordNet v1.6
> dict-web1913 - 1913 Webster's Dictionary
> miscfiles - Dictionaries and other interesting files.
> 

The goal of the proposal is to NOT dicate what goes in this section but to
create the section and allow it to be filled by common sense.  Large data
objects like census data, geographical surveys, astronomical data should go
in there.  What does common sense tell you about dictionary files?

-- 
Please cc all mailing list replies to me, also.
=========================================================================
* 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>   *
=========================================================================

[Message part 2 (application/pgp-signature, inline)]

Message #40 received at 38902@bugs.debian.org (full text, mbox, reply):

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

To: Oliver Elphick <olly@lfix.co.uk>, 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Fri, 4 Jun 1999 10:01:03 -0700

[Message part 1 (text/plain, inline)]

On Fri, Jun 04, 1999 at 04:29:26PM +0100, Oliver Elphick wrote:
> bible-kjv-text is the data, bible-kjv the program.
> 
> bible-kjv could theoretically handle any text in the same way as the bible,
> but no other text has been formatted for it to work on.
If were as strict as Brandon says... it's up to the package maintainer... 
if he wants to "Depend:" bible-kjv on bible-kjv-text, they go into data.
If bible-kjv only "Recommends:" or less it can go in to main with the data
in data.

> verse doesn't use bible-kjv-text for its source, but a compilation of
> quotes that its original author put together.  It is actually a rather
> small package, with a 38Kb deb, including the verses.  It's on a par
> with, say, fortune.  I don't think it really fits the purpose of data.
If verse doesn't depend on a seperate data package... then it goes into
main.

-- 
Please cc all mailing list replies to me, also.
=========================================================================
* 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>   *
=========================================================================

[Message part 2 (application/pgp-signature, inline)]

Message #45 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Edward Betts <edward@debian.org>

To: 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Fri, 4 Jun 1999 18:50:54 +0100

On policy, Oliver Elphick <olly@lfix.co.uk> wrote:
> verse doesn't use bible-kjv-text for its source, but a compilation of
> quotes that its original author put together.  It is actually a rather
> small package, with a 38Kb deb, including the verses.  It's on a par
> with, say, fortune.  I don't think it really fits the purpose of data.

#Package: verse
#Priority: optional
#Section: doc
#Installed-Size: 125
#Maintainer: Oliver Elphick <Oliver.Elphick@lfix.co.uk>
#Architecture: i386
#Version: 0.20
#Depends: libc6, bible-kjv
 So what is this ^^^^^^^^^ !
#Filename: dists/unstable/main/binary-i386/doc/verse_0.20.deb
#Size: 37546
#Version: 0.20
#Depends: libc6, bible-kjv
#Filename: dists/unstable/main/binary-i386/doc/verse_0.20.deb
#Size: 37546
#MD5sum: c9d4514fe1b342fa3e7cf0db12be8c8b
#Description: Daily Devotional Verse from KJV Bible
# Verse displays a Bible Verse on each login. A verse from the King James
# Version of the Bible is assigned to each day.
# .
# There is also a program to display a verse chosen at random.


-- 
I consume, therefore I am

Message #50 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Fabien Ninoles <fab@tzone.org>

To: 38902@bugs.debian.org

Subject: Bug#38902: PROPOSED] data section

Date: Fri, 4 Jun 1999 18:46:47 -0400

> The data section would be governed by the following rules:
> - No package can depend on a package in data.

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 
other theme (like ShinyMetal) in data.

> - No package with an executable can go into data unless it is useable ONLY
>  with a dataset in data.

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.

> - 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 section
>   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...

> reason:
> - The data subdirectory is an entire part of Debian. Its purpose is to
>   let the CD vendors/archives maintainers/users choice between a Debian
>   Light who fit on a reasonable amount of CDs, and an Debian Extended who
>   can fill your entire RAID array.

This really looks like from me ;)
Don't care much, all my mail are DFSG-free and I forgive you
to not say it was from me ;)

Regards,

------------------------------------------------------------------------
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
------------------------------------------------------------------------

Message #55 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Fabien Ninoles <fab@tzone.org>

To: 38902@bugs.debian.org, "Darren O. Benham" <gecko@debian.org>, Steve Greenland <stevegr@debian.org>

Subject: Re: Bug#38902: PROPOSED] data section

Date: Fri, 4 Jun 1999 18:54:54 -0400

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

> On Thu, Jun 03, 1999 at 07:33:03PM -0500, Steve Greenland wrote:
> > A few additional rules for your consideration:
> > 
> > - The data directory shouldn't be synced to debian releases, and ought
> >   to be paralled to dists, not main/contrib/non-free.
> >   (Since there are no executables, what's the benefit of syncing it, with
> >    the presumed multiplying of size and hassle? If a dataset needs a
> particular
> >    program or version, a simple dependency should be enough.)
> I thought about this... but in the case of a format change, a reader would
> have to be downloaded out of unstable (if you have a stable dist) or the
> data would have to wait until unstable is stablized.  If there is no change
> in the data, then symlinks should suffice to not create a duplicate of
> data.  Espcially if they DON'T change very often.

Agree with Darren on this.  Even if they're not likely, data packages
can depends on version. Maybe when we got a different way for handling
the Releases cycles we could make it but it's currently too much difficult,
IMHO.

> 
> > A thought: Do we need to keep a source archive separate from the .deb?
> > Almost all of these package are effectively their own source, and since
> > we are talking about large datasets, the burden of keeping both seems
> > unnecessary. Before you light up the flamethrower, I'm not promoting the
> > idea of not releasing source. But consider a package that is basically
> > a reproduction of a website. Do we really need two 7Mb packages who's
> > fundamental difference is that they unpack into a different location?
> > Instead, we could make the .debs act like installers, except that
> > they would grab the external archive from the CD or via http. Or have
> > a /usr/doc/<package>/debian, whose rules file has a way to copy the
> > installed data into a new tree in order to rebuild the package.
> Very good point.   From what I understand, ammendments to proposals should
> be "convince the proposer" so if you agree with this, steve, consider me
> convinced to amend as follows:
> 
> - Data debs should include all files from the original, upstream source
>   installed into proper directories for Debian's requirements.  So being,
>   a seperate source archive need not be kept.

Change in the format of source-file implied really too much change.
How dinstall will handle those files? Where the files will appear?
Only in all arch? In source? In which format? Deb or orig.tar.gz?
Remember that some people only buy source CDs.

Also, I don't think this is need in this proposal. So, consider I object
to this amendment, and suggest you, instead, to move it to another
proposal or fill a bug against dpkg-dev or ftp.debian.org or dinstall,
whichever you care.

> > 
> > Steve
> > 
> > 
> 
> -- 
> Please cc all mailing list replies to me, also.
> =========================================================================
> * 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>   *
> =========================================================================
> 
> 

Regards,

------------------------------------------------------------------------
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
------------------------------------------------------------------------

Message #60 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Fabien Ninoles <fab@tzone.org>

To: Branden Robinson <branden@ecn.purdue.edu>, 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Fri, 4 Jun 1999 19:16:20 -0400

Quoting Branden Robinson <branden@ecn.purdue.edu>:

> On Fri, Jun 04, 1999 at 09:27:57AM +0100, Edward Betts wrote:
> > What kind of packages are we thinking of for data?
> >=20
> > Web mirrors?
> > anarchism - An exhaustive exploration of Anarchist theory and practice.
> > gimp-manual - Manual for the GNU Image Manipulation Program
> > gnu-philosophy - Philosophy of the GNU Project
> > jargon-html - The definitive compendium of hacker slang.
> >=20
> > Funny manpages?
> > asr-manpages - alt.sysadmin.recovery manual pages
> > funny-manpages - more funny manpages
> >=20
> > Magazine back issues?
> > heise-register - register of the magazines c't, iX, Elrad and Gateway
> > lg-base - Shared files for the Linux Gazette.
> > lg-issue01to08 - Issues 1 to 8 of the Linux Gazette.
> > lg-issue* - Issue * of the Linux Gazette.
> > pj-* - * * number of Pluto Journal.
> >=20
> > Technical documents?
> > bible-kjv-text - King James Version of the Bible - text and concordance
> > doc-rfc - Important RFCs
> >=20
> > Dictionaries?
> > dict-easton - Easton's 1897 Bible Dictionary
> > dict-elements - Data regarding the Elements
> > dict-foldoc - FOLDOC Dictionary Database
> > dict-gazetteer - U.S. Gazetteer
> > dict-hitchcock - Hitchcock's Bible Names Dictionary
> > dict-jargon - Jargon File 4.0.0
> > dict-wn - WordNet v1.6
> > dict-web1913 - 1913 Webster's Dictionary
> > miscfiles - Dictionaries and other interesting files.
> 
> I wouldn't mind seeing all of these move into the data section.
> 
> There's no point having a data section if we're not going to be consistent
> about how we use it, and if we're not going to try very, very hard to keep
> our criteria objective (i.e., no arguments like "the Jargon file can stay
> but the Bible has to go").
> 
> I don't really regard bible-kjv-text as a technical document, but... :)

Remember one thing, in the proposal, the maintainer as some right to do it.
I don't want to see arbitrary decision about this. data is not like
non-free. We don't have any clear guideline to decide either one package
should go or not in data except for the depends part (which is technical).

That's why the proposal refers to the section models. The proposal is not
even accept already, we better to discussed if we keep the same sections
or not. That's a more important thing. After that, people can feel bugs
against ftp.debian.org to move their packages in data if it seems right
to them. I'm pretty sure things will go smoothly and I think, IMVHO,
that we dont need "consistent way" (I look at it like "formal") to use
it, just like we don't have one for sections. Hope I interpret it
correctly.

> 
> If I understood the proposal correctly, bible-kjv and verse would both go
> into the new data section.  "verse" because it's designed to work only with
> only one data file -- bible-kjv.

That's a good example of if a software package can go or not in data.
IMHO, removing it from main will just remove choice seens main should
contain ALL the functionalities of Debian (either people think there are
or not functionnalities in verse), and data just add to it with options.

The frontier is really blur here, contrary to the legal assumptions of main
(DFSG rules), and just like the way sections are provided. Please, let it
be on a per packages basis, just like the section thing.

> 
> --=20
> G. Branden Robinson              |   A celibate clergy is an especially
> good
> Debian GNU/Linux                 |   idea, because it tends to suppress any
> branden@ecn.purdue.edu           |   hereditary propensity toward
> fanaticis=
> m.
> cartoon.ecn.purdue.edu/~branden/ |   -- Carl Sagan
> 

Regards,

------------------------------------------------------------------------
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
------------------------------------------------------------------------

Message #65 received at 38902@bugs.debian.org (full text, mbox, reply):

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

To: Fabien Ninoles <fab@tzone.org>, 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Fri, 4 Jun 1999 20:00:52 -0700

[Message part 1 (text/plain, inline)]

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.
> 
> 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 
> 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.

> 
> > - No package with an executable can go into data unless it is useable ONLY
> >  with a dataset in data.
> 
> 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.

> 
> > - 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 section
> >   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.

> 
> > reason:
> > - The data subdirectory is an entire part of Debian. Its purpose is to
> >   let the CD vendors/archives maintainers/users choice between a Debian
> >   Light who fit on a reasonable amount of CDs, and an Debian Extended who
> >   can fill your entire RAID array.
> 
> This really looks like from me ;)
It was, with some modifications.  I thought I have you the credit at the
top... from you by the way of another person's email.. forgot who off the
top of my head

> Don't care much, all my mail are DFSG-free and I forgive you
> to not say it was from me ;)
> 

-- 
Please cc all mailing list replies to me, also.
=========================================================================
* 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>   *
=========================================================================

[Message part 2 (application/pgp-signature, inline)]

Message #70 received at 38902@bugs.debian.org (full text, mbox, reply):

From: "Oliver Elphick" <olly@lfix.co.uk>

To: Edward Betts <edward@debian.org>, 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Sat, 05 Jun 1999 22:00:34 +0100

Edward Betts wrote:
  >On policy, Oliver Elphick <olly@lfix.co.uk> wrote:
  >> verse doesn't use bible-kjv-text for its source, but a compilation of
  >> quotes that its original author put together.  It is actually a rather
  >> small package, with a 38Kb deb, including the verses.  It's on a par
  >> with, say, fortune.  I don't think it really fits the purpose of data.
  >
  >#Package: verse

  >#Depends: libc6, bible-kjv

  >#Description: Daily Devotional Verse from KJV Bible
  ># Verse displays a Bible Verse on each login. A verse from the King James
  ># Version of the Bible is assigned to each day.
  ># .
  ># There is also a program to display a verse chosen at random.
 
A bug! That should be moved out, leaving verse as a stand-alone.
Since there are no upstream changes on these packages, I had forgotten this.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "Let your conversation be without covetousness; and be 
      content with such things as ye have. For he hath said,
      I will never leave thee, nor forsake thee."      
                                             Hebrews 13:5 

Message #75 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: Branden Robinson <branden@ecn.purdue.edu>, 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Sat, 5 Jun 1999 14:00:42 -0700

Branden Robinson wrote:
> If I understood the proposal correctly, bible-kjv and verse would both go
> into the new data section.  "verse" because it's designed to work only with
> only one data file -- bible-kjv.

That's silly. 'passwd' is a program designed to work with only 1 data file,
I don't think that puts it in data. 

I'm opposed to putting any binaries in data.

-- 
see shy jo

Message #80 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de>

To: Steve Greenland <stevegr@debian.org>

Cc: 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: 07 Jun 1999 11:06:00 +0200

Steve Greenland <stevegr@debian.org> writes:

> A few additional rules for your consideration:
> 
> - The data directory shouldn't be synced to debian releases, and ought
>   to be paralled to dists, not main/contrib/non-free.
>   (Since there are no executables, what's the benefit of syncing it, with
>    the presumed multiplying of size and hassle? If a dataset needs a particular
>    program or version, a simple dependency should be enough.)
> 
> A thought: Do we need to keep a source archive separate from the .deb?

We need source for license reasons. Do we need debs?

Most dataset packages are real easy to compile, i.e. copy the data to
its dir. apt can download, unpack, compile and install source packages 
and for datasets this is mostly so trivial that it cannot fail. I
think source packages would be enough.

> Almost all of these package are effectively their own source, and since
> we are talking about large datasets, the burden of keeping both seems
> unnecessary. Before you light up the flamethrower, I'm not promoting the
> idea of not releasing source. But consider a package that is basically
> a reproduction of a website. Do we really need two 7Mb packages who's
> fundamental difference is that they unpack into a different location?
> Instead, we could make the .debs act like installers, except that
> they would grab the external archive from the CD or via http. Or have
> a /usr/doc/<package>/debian, whose rules file has a way to copy the
> installed data into a new tree in order to rebuild the package.

Distributing datasets as source also has the advantage that we can
distribute diffs. Its stupid to distribute 50 MB of datas in a deb
file, just because 5K of data has changed. With sources the maintainer 
would make a snapshot of the data to generate a orig.tar.gz and then
make diffs to current data. If the diff grows to much, make anotehr
orig.tar.gz and so on.

May the Source be with you.
			Goswin

Message #85 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de>

To: Joey Hess <joey@kitenet.net>

Cc: 38902@bugs.debian.org, Branden Robinson <branden@ecn.purdue.edu>

Subject: Re: Bug#38902: PROPOSED] data section

Date: 07 Jun 1999 11:16:47 +0200

Joey Hess <joey@kitenet.net> writes:

> Branden Robinson wrote:
> > If I understood the proposal correctly, bible-kjv and verse would both go
> > into the new data section.  "verse" because it's designed to work only with
> > only one data file -- bible-kjv.
> 
> That's silly. 'passwd' is a program designed to work with only 1 data file,
> I don't think that puts it in data. 
> 
> I'm opposed to putting any binaries in data.

But wouldn't be in the data section. if it would, what would be the
point of passwd in main?

Anything in main that depends on something in data shoulbe eigther be
moved to data or the data should be moved to main.

May the Source be with you.
			Goswin

Message #90 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Fabien Ninoles <fab@tzone.org>

To: "Darren O. Benham" <gecko@debian.org>, 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Mon, 7 Jun 1999 17:58:06 -0400

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
------------------------------------------------------------------------

Message #95 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Fabien Ninoles <fab@tzone.org>

To: 38902@bugs.debian.org

Subject: Re: Bug#38902: PROPOSED] data section

Date: Mon, 7 Jun 1999 18:09:06 -0400

Quoting Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de>:

> Joey Hess <joey@kitenet.net> writes:
> 
> > Branden Robinson wrote:
> > > If I understood the proposal correctly, bible-kjv and verse would both
> go
> > > into the new data section.  "verse" because it's designed to work only
> with
> > > only one data file -- bible-kjv.
> > 
> > That's silly. 'passwd' is a program designed to work with only 1 data
> file,
> > I don't think that puts it in data. 
> > 
> > I'm opposed to putting any binaries in data.
> 
> But wouldn't be in the data section. if it would, what would be the
> point of passwd in main?
> 
> Anything in main that depends on something in data shoulbe eigther be
> moved to data or the data should be moved to main.

Although I agree with you, in the spirit of my original draft, this choice
should not be write in the Policy because we can't really make a clear line
between what's need to be in main, and what's not. Astronomical data are
clearly big enough to be in data. lg issues are also good candidates.
But a small package like verses is more blured. Removing it will also
remove fortunes, and, BTW, gl-screensavers and games for irrelevance
from being parts of a workable Unix System. But people don't wan't this.

So don't make it a policy and let's decide it on a per package basis, just
like the sections field.

As for dependencies, consider data to be like a lesser priority than
extra or optional (don't remember which one is the lowest). The Policy
already that no packages should depends on priority lesser than itself.
I thinks it's should make things right.

> 
> May the Source be with you.
> 			Goswin
> 
> 

Regards,

------------------------------------------------------------------------
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
------------------------------------------------------------------------

Message #100 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Peter Makholm <peter@makholm.net>

To: 38902@bugs.debian.org

Subject: Re: Bug#38902: [PROPOSED] data section

Date: 28 Jun 1999 13:57:25 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Darren O. Benham writes:

> Since there is interest in packaging census data, maps, genome data
> and other huge datasets I and since most people agreed that dropping them
> in main or contrib is not a great idea, I propose the creation of a data
> section to reside along side of main, contrib and non-free.

I read in the weekly policy news that this proposal was stalled. I
have been a litle busy lately so I havn't had the time to follow it.

After reading the mail archive I believe that this proposal is better
than nothing. To make a long message short:

I second this proposal.

- -- 
I congratulate you. Happy goldfish bowl to you, to me, to everyone,
and may each of you fry in hell forever. 
                                    -- Isaac Asimov, "The Dead Past"

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.5.3, an Emacs/PGP interface

iQCVAwUBN3djCEbzQI+vWRzFAQHJPAP8DPR9Di0kpQ2DCiXSqXLOpBt13KgHKF3K
kqLuKeD5ZZ1xapFDPO8HtPW4eU59EBJHNgPstYXlN64bV3BQh5h4Cip9fOuXImKH
v2FmMJD3XejAUJxdHWytq5TII8VrI16qLXgO0N4y2+mugLvsVY2a6rT9SnJpXLxm
RIy+DpOEGy4=
=qo1H
-----END PGP SIGNATURE-----

Message #105 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

To: 38902@bugs.debian.org

Cc: debian-policy@lists.debian.org

Subject: Bug#38902: [PROPOSED] data section

Date: Tue, 29 Jun 1999 09:17:22 -0400

-----BEGIN PGP SIGNED MESSAGE-----


Darren O. Benham <gecko@debian.org> wrote

> This is Fabian's proposal with a few modifications.

I second this proposal.

Peter

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.5b7, an Emacs/PGP interface

iQCVAwUBN3jHXLwVH8jSqROhAQG5MAP/aW34JzILkVGBzbbGeMUH3MTAFKY5FWhN
pkeGKyj0cSFr+wGaoUsWckThN2bTYJ+zcVHk09KtDDPSWm4bVz8eusUfcN5AEwBZ
AvPNC81OpMobdhwvcOjQ5CYSLb+fWKh/AAzIZTytdwc/k/nb9AYfSWohDyf0rHbL
MJgUiwcRIN0=
=dgLV
-----END PGP SIGNATURE-----

Message #110 received at 38902@bugs.debian.org (full text, mbox, reply):

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

To: 38902@bugs.debian.org

Subject: Data section

Date: Fri, 2 Jul 1999 13:56:43 -0700

[Message part 1 (text/plain, inline)]

On Fri, Jul 02, 1999 at 01:42:58PM -0700, Joey Hess wrote:
> Data section (#38902)
>   * Under discussion.
>   * Proposed on 3 Jun 1999 by Darren O. Benham; seconded by Peter S
>     Galbraith.
I thought there was another second...??

>   * "Since there is interest in packaging census data, maps, genome
>     data and other huge datasets I and since most people agreed that
>     dropping them in main or contrib is not a great idea, I propose
>     the creation of a data section to reside along side of main,
>     contrib and non-free." Includes rules about what goes in this
>     section.
Either way, is there anybody that has an objection to this proposal?

-- 
Please cc all mailing list replies to me, also.
=========================================================================
* 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>   *
=========================================================================

[Message part 2 (application/pgp-signature, inline)]

Message #115 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: "Darren O. Benham" <gecko@debian.org>, 38902@bugs.debian.org, debian-policy@lists.debian.org

Subject: Re: Bug#38902: Data section

Date: Fri, 2 Jul 1999 14:19:51 -0700

Darren O. Benham wrote:
> On Fri, Jul 02, 1999 at 01:42:58PM -0700, Joey Hess wrote:
> > Data section (#38902)
> >   * Under discussion.
> >   * Proposed on 3 Jun 1999 by Darren O. Benham; seconded by Peter S
> >     Galbraith.
> I thought there was another second...??

Oh, my mistake. Two Peter's seconded it and I though the second one was a
dup. I've been reading too fast lately.

> Either way, is there anybody that has an objection to this proposal?

Good question.

-- 
see shy jo

Message #120 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Fabien Ninoles <fabien@Nightbird.TZoNE.ORG>

To: 38902@bugs.debian.org

Subject: Re: Bug#38902: Data section

Date: Sat, 3 Jul 1999 16:55:30 -0400

[Message part 1 (text/plain, inline)]

On Fri, Jul 02, 1999 at 02:19:51PM -0700, Joey Hess wrote:
> Darren O. Benham wrote:
> > On Fri, Jul 02, 1999 at 01:42:58PM -0700, Joey Hess wrote:
> > > Data section (#38902)
> > >   * Under discussion.
> > >   * Proposed on 3 Jun 1999 by Darren O. Benham; seconded by Peter S
> > >     Galbraith.
> > I thought there was another second...??
> 
> Oh, my mistake. Two Peter's seconded it and I though the second one was a
> dup. I've been reading too fast lately.

BTW, I seconded also and just think that you can merge it with this
informal proposal I made. It's really the same thing (except for a word
or two), just in a more formal way ;)

[from the weekly review:]
> Let's Debian blow... gracefully!
> * Old.
> * Proposed by Fabien Ninoles; seconded by Sean E. Perry, Edward
>   Betts and Peter Makholm.
> * Creation of a sub-directory aside from main, contrib, non-free
>   named data, that will hold non-program related data.
[back to previous quotes]
			    
> 
> > Either way, is there anybody that has an objection to this proposal?

Just recall some add-ons made (sorry, it should be somewhere in the
mailing list) about new forms of (sub)sections [something like having
everything under /Sound/Players/{Main,Contrib,Non-Free} instead of
the way it was now. IIRC, I reply that's this is not really relevent
to the proposal but to apt/dselect, and, even if I consider that new
sections can be needed, it should be made a new proposal.

I don't anything in those mails can be considered as an objections,
even an amendments.

> 
> Good question.
> 

The answer should be in the BTS now :).

> -- 
> see shy jo
> 

-- 
------------------------------------------------------------------------
Fabien Ninoles                                             GULUS founder
aka Corbeau aka le Veneur Gris               Debian GNU/Linux maintainer
E-mail:                                                    fab@tzone.org
WebPage:                      http://www.callisto.si.usherb.ca/~94246757
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99  4F 80 2D 2D 1F 85 C1 70
------------------------------------------------------------------------

[Message part 2 (application/pgp-signature, inline)]

Message #134 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@cibalia.gkvk.hr>

To: 38902@bugs.debian.org, 46516@bugs.debian.org, 45406@bugs.debian.org, 41547@bugs.debian.org, 45307@bugs.debian.org, 39299@bugs.debian.org

Subject: Re: [bi]weekly policy summary

Date: Sun, 10 Oct 1999 19:20:10 +0200

-----BEGIN PGP SIGNED MESSAGE-----

On Sat, Oct 09, 1999 at 07:27:05PM -0700, Joey Hess wrote:
> Data section (#38902)
>   * Consensus.
>   * Proposed on 3 Jun 1999 by Darren O. Benham; seconded by Peter S
>     Galbraith and Peter Makholm.
>   * "Since there is interest in packaging census data, maps, genome
>     data and other huge datasets I and since most people agreed that
>     dropping them in main or contrib is not a great idea, I propose
>     the creation of a data section to reside along side of main,
>     contrib and non-free." Includes rules about what goes in this
>     section.

Seconded.

> MIME support sub-policy
>   * Under discussion.
>   * Proposed by J.H.M. Dassen; seconded by Raul Miller, Wichert
>     Akkerman and Chris Waters.
>   * Adds section to policy about registration as a MIME handler. The
>     added section references a new mime sub-policy document. This
>     proposal just documents existing practice.

That is bug #46516, and I'd like to second it, FWIW.

> Config files must have manpages (#45406)
>   * Stalled.
>   * Proposed by Nicolás Lichtmaier; seconded by Oliver Elphick and
>     Josip Rodin.
>   * Require every config file have a man page.

Note that my wording hasn't been approved 100% by the proposer and
other seconder - frankly, I'm having second thoughts about it,
considering the amount of files which would need to get a manpage...
seems rather pointless.

> Correct section 3.3 to take account of file-rc (#41547)
>   * Old.
>   * Proposed by Julian Gilbey; seconded by Roland Rosenfeld and
>     Anthony Towns.
>   * Part of policy doesn't make sense if file-rc is being used. This
>     proposal is to clean it up so it does make sense, and moreover so
>     it emphasizes that update-rc.d is the only thing that should be
>     used to register init scripts.

Seconded.

> Virtual package ident-server (#45307)
>   * Stalled.
>   * Proposed by Chris Lawrence; seconded by Sean 'Shaleh' Perry.
>   * Proposes a "ident-daemon" virtual package.

Seconded.

> Permit/require use of bz2 for source packages (#39299)
>   * Old.
>   * Proposed on 10 Jun 1999 by Chris Lawrence; seconded by Goswin
>     Brederlow.
>   * "I propose that we permit the use of bzip2 to compress source
>     package files (.orig.tar and .diff for most packages, .tar for
>     native packages). I further propose that the use of bzip2 be
>     mandatory for newly uploaded source files, and that any existing
>     source packages in the archive in gzip format exceeding 5 MB of
>     compressed space be converted upon the freeze for potato."
>     ( The reason this was proposed is because we're almost overflowing
>     the second source CD already. This is a very contentious proposal. )

Seconded.

- -- 
enJoy -*/\*- don't even try to pronounce my first name

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBOADKVIdGxXDOoJfVAQE8iQP/VoAxViqIeRfKl1u3Qt7rm0jOTwiK5+qR
39pbTI0ZHvYo0J514rkQxZWLdvAKpK5psahWV0q91mSPLxZ8vn148tSiV39C6aRt
AkjDihOVRE6KY92WrDruEVGf3LVdR0mNgSDN2GcECIYQl1ptHdY0HgGkDuivlNyI
C14s2M/ZREM=
=dree
-----END PGP SIGNATURE-----

Message #139 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: Josip Rodin <joy@cibalia.gkvk.hr>, 38902@bugs.debian.org

Cc: 46516@bugs.debian.org, 45406@bugs.debian.org, 41547@bugs.debian.org, 45307@bugs.debian.org, 39299@bugs.debian.org

Subject: Re: Bug#38902: [bi]weekly policy summary

Date: Sun, 10 Oct 1999 12:22:52 -0700

[Message part 1 (text/plain, inline)]

On Sun, Oct 10, 1999 at 07:20:10PM +0200, Josip Rodin wrote:
> > Permit/require use of bz2 for source packages (#39299)
> >   * Old.
> >   * Proposed on 10 Jun 1999 by Chris Lawrence; seconded by Goswin
> >     Brederlow.
> >   * "I propose that we permit the use of bzip2 to compress source
> >     package files (.orig.tar and .diff for most packages, .tar for
> >     native packages). I further propose that the use of bzip2 be
> >     mandatory for newly uploaded source files, and that any existing
> >     source packages in the archive in gzip format exceeding 5 MB of
> >     compressed space be converted upon the freeze for potato."
> >     ( The reason this was proposed is because we're almost overflowing
> >     the second source CD already. This is a very contentious proposal. )
> 
> Seconded.

I really think the "require" and "mandatory" parts are a Bad Plan.  If bz2
support is ACTUALLY WRITTEN I would support policy that recommends using
bz2 if upstream does.  I think people with huge packages will do the right
thing because it's the right thing in almost all cases.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
Now I can finally explain to everyone why I do this.  I just got $7 worth
of free stuff for working on Debian !

[Message part 2 (application/pgp-signature, inline)]

Message #144 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@cibalia.gkvk.hr>

To: Joseph Carter <knghtbrd@debian.org>, 38902@bugs.debian.org

Cc: 38902-submitter@bugs.debian.org

Subject: Re: Bug#38902: bi]weekly policy summary

Date: Mon, 11 Oct 1999 15:37:36 +0200

[cut the CC: field!]

On Sun, Oct 10, 1999 at 12:22:52PM -0700, Joseph Carter wrote:
> > > Permit/require use of bz2 for source packages (#39299)
> > >   * Old.
> > >   * Proposed on 10 Jun 1999 by Chris Lawrence; seconded by Goswin
> > >     Brederlow.
> > >   * "I propose that we permit the use of bzip2 to compress source
> > >     package files (.orig.tar and .diff for most packages, .tar for
> > >     native packages). I further propose that the use of bzip2 be
> > >     mandatory for newly uploaded source files, and that any existing
> > >     source packages in the archive in gzip format exceeding 5 MB of
> > >     compressed space be converted upon the freeze for potato."
> > >     ( The reason this was proposed is because we're almost overflowing
> > >     the second source CD already. This is a very contentious proposal. )
> > 
> > Seconded.
> 
> I really think the "require" and "mandatory" parts are a Bad Plan.  If bz2
> support is ACTUALLY WRITTEN I would support policy that recommends using
> bz2 if upstream does.  I think people with huge packages will do the right
> thing because it's the right thing in almost all cases.

The whole proposal depends on better implementation in dpkg and other tools
(you can use tar.bz2 archives, but only under tar.gz archives :( ).
Until then, my second is worthless, too.

Policy maintainer, maybe you should close/reject this, as it doesn't seem we
will be possible to properly support it with working code RSN...

-- 
enJoy -*/\*- don't even try to pronounce my first name

Message #152 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 38902@bugs.debian.org, gecko@debian.org

Subject: Bug#38902: [ACCEPTED 07/16/99] Data section

Date: Wed, 27 Oct 1999 15:53:22 +0100 (BST)

What's the actual wording which should go into policy?

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg

Message #155 received at 38902-submitter@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 38902-submitter@bugs.debian.org

Subject: Bug#38902: Data section

Date: Thu, 28 Oct 1999 20:24:41 +0100 (BST)

Did you really intend to mark this bug as fixed?

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg

Message #158 received at 38902-quiet@bugs.debian.org (full text, mbox, reply):

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

To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>, 38902-quiet@bugs.debian.org

Subject: Re: Bug#38902: Data section

Date: Thu, 28 Oct 1999 14:35:02 -0700

[Message part 1 (text/plain, inline)]

I didn't.... ?

Ok.. so I did.  I would guess that joeyh or someone suggested it to me now
that the amendment was accepted... I'm not fully versed in the -policy
amendment process so I rely on the guiding of others.

On Thu, Oct 28, 1999 at 08:24:41PM +0100, Julian Gilbey wrote:
> Did you really intend to mark this bug as fixed?
> 
>    Julian
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
>   Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
>         Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
> 

-- 
Please cc all mailing list replies to me, also.
=========================================================================
* 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>   *
=========================================================================

[Message part 2 (application/pgp-signature, inline)]

Message #163 received at 38902@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: Debian Email Bug Control <control@bugs.debian.org>

Cc: 38902@bugs.debian.org

Subject: Reassign bug to ftp.debian.org

Date: Fri, 23 Jun 2000 17:16:10 +0100

reassign 38902 ftp.debian.org
severity 38902 normal
thanks

The creation of the data section now rests in the hands of the ftp
team.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Message #180 received at 38902-done@bugs.debian.org (full text, mbox, reply):

From: Mike O'Connor <stew@debian.org>

To: 82434-done@bugs.debian.org, 38902-done@bugs.debian.org, 220289-done@bugs.debian.org, 250040-done@bugs.debian.org, 269180-done@bugs.debian.org

Subject: Requested sections not added

Date: Sun, 15 Mar 2009 12:44:10 -0400

[Message part 1 (text/plain, inline)]

Recently the ftp team decided to add new secitons to the archive[1], but
decided that the section you requested wasn't warranted.  We'd recommend
that instead you make sure that packages which would go into your
requested section are instead tagged appropriately using debtags[2]

thanks,
stew

[1] http://lists.debian.org/debian-devel-announce/2009/03/msg00010.html
[2] http://debtags.alioth.debian.org/

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.