Re: Data does NOT belong in Debian (was: Stop Archive bloat)
On Tue, Oct 19, 1999 at 11:37:06PM +0200, Petr Cech wrote:
> On Tue, Oct 19, 1999 at 07:10:09PM +0000 , Zygo Blaxell wrote:
> > On 18 Oct 1999 18:16:58 -0700, Philippe Troin <phil@fifi.org> wrote:
> [snip]
> > > 3) Where do we stop ? As someone says, there's nothing preventing
> > > me from uploading as debian package every single .wav or .mov
> > > file on the Internet just because it's useful.
> >
> > This is the real problem. Some things just don't belong in Debian,
> > even though they legally and technically can be distributed via Debian.
See more discussion on the policy proposal of the data section (accessible
via the BTS ;). The Debian Policy don't try to resolve abuse of the system.
We are mature enough to detect such abuse (new 3GB package will have to
go by ftp-maintainers who I hope aren't foul enough to let it install in
the archives !) and discuss if we can accept or not such package.
The proposal also deal with contents: anything dfsg. It not says that
we must accept anything! In fact, I never like the fact that the policy
should take some judgement value. The only one that I explicitely with,
as all the developpers, is the DFSG. No other constraint except from a
legal point of view (which is implicit to our society).
Take also in note that the data is just a first step. Nothing forbid us
to granulate data in text, doc, themes, etc... and make them mirrored
separately on different site just like non-us (eh! no body has to mirror
non-free or experimental or Incoming, why forcing people to mirror data
now?). Because packages in main or contrib can't depends over packages
in data, data is really optionnal and can be handled independently.
Data CDs can be build and registered in apt like a seperate secondary
source. apt should install packages in the Official CDs first (including
vendors add-on) and after that asking for the other Data CDs. Currently,
there are no support for this in apt but I don't is so much trouble to
add some. It's nothing complicated like the dependencies of the current
CD-chains. Two steps: Do Officials Set first, then do Data Set(s) in
independant order.
I'm one of the proposer of data. The original one was titled "let
Debian blow gracefully" and was meant to let people have choice. Choice
to not mirror everything, choice to have access to data useful for them,
choice to have a good set of data they know they can use freely (in dfsg
sense). Personnaly, I always tick to the copyright of the eterm-backgrounds.
They came from the digitalblasphemy site and lot of them are now only
accessible to members... but that's another story. The proposal accepted
still repeat this: No constraint except two things: DFSG and Independance
over main.
> >
> > >This is what I believe are acceptable "pure data" packages:
> > > 1) Data which is absolutely required for a program to work.
This should not go in data! See the proposal for that!
> >
> > Hmmm...what about theme packages for desktops? Will Debian allow packages
> > of sound files, icons, patterns, and color selections for GNOME etc?
>
> they are already there: gnome-audio(3MB), eterm-backgrounds (8MB) and propably
> some other (not to mention the infamous gmt- packages)
>
> > > 3) Documentation (documentation packages should still remain).
> >
> > Make that "documentation for other non-data packages in Debian."
> >
> > What happens when people start releasing packages with MPEG format
> > training videos instead of text documentation?
>
> yuck.
>
> > > 4) Small examples or data sets.
> >
> > "Illustrative" examples might be a better term. "Small" is ill-defined;
> > a "small" MPEG-2 example file might be dozens of megabytes.
>
> :)
>
> > >Pros of this policy:
> > > 1) Makes Debian smaller.
Data proposal let main be smaller than even now (by let it remove some
themes, lg issues, some special formatted docs, extra packages, etc),
while still offering choice to people who want the big set. It also
let the mirrors choose between mirroring a Small and Lean Debian, or
a Big and Ressourceful Debian. Currently, there no easy to do that
(you would have to distinguish between standard packages and extra/optional
one). All that without restreigning Debian in any way.
> > > 2) Avoids controversial materials (politics and religious texts)
> >
> > I can see it now...
> >
> > "Debian bans the bible but keeps all the foul language in the xscreensaver
> > sources. What has this world come to? Somebody, think of the children!"
> >
> > ;-)
Yes, and all the nudes in eterms-backgrounds too [ trust me, I have to remove
it from my backgrounds at a previous jobs !! ]. Remember: people at Debian
have only three contraint: the Constitution, the DFSG Policy, and the Law.
This include the opinion of developpers as a whole and the will of the
maintainer of a package. We have to deal with both in a reasonable way.
> >
> > >Cons:
> > > 1) People which don't have access to the net find these packages
> > > invaluable...
> > > Reply: Yes, then create a separate project "WebDeb" with the goal
> > > of packaging anything in the .deb format.
> >
> > I think this is by far the best solution, but I think Debian should be
> > broken up into smaller, more independent pieces anyway. ;-)
That's address with data.
>
> this could be done not - priorities (I know, they are not always correct)
This too (if you mean, like I think, dependencies vs priorities, instead of
just priorities).
> >
> > ..deb is really just a tarball with extra information on the package and
> > some guidelines for what should be inside it. It's much cleaner as a
> > "pure data" encapsulation format for distribution than some of the things
> > other people use, e.g. self-installing Win32 .EXE files.
> >
> > As other people pointed out, there are other advantages to having pure
> > data in .deb format: easy distribution via apt, and management of the
> > files when they're installed on the system.
>
> so build a program that inserts the information about files unpacked from
> downloaded archive. It could be useful also for other packages (rvplayer comes
> to mind).
See also my previous mail on the same thread about the special Source-Only
package. The overhead can go down near to nothing and can be easy to
implement. I also proposed something on debian-doc (look for my name this
month) about handling of i18n who can also address issue like not installing
some parts of the files through a dpkg-divert to /dev/null mecanism. This
can save lot of space on installation too.
>
> Petr Cech
> --
> Debian GNU/Linux maintainer - www.debian.{org,cz}
> cech@atrey.karlin.mff.cuni.cz
>
--
------------------------------------------------------------------------
Fabien Ninoles Chevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris 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: