Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb
On Tue, Oct 19, 1999 at 08:47:45AM +0200, Sven LUTHER wrote:
> On Mon, Oct 18, 1999 at 08:49:53AM -0700, Philippe Troin wrote:
> > > What happened to the data section project, this gmt package is just data, the
> > > worlds coastline in very detailled format i think. It is useful, and is not a
> > > bloat. A bloat was when there were more than two version of the x sources
> > > around, the normal one and one for ARM or something like that.
> >
> > I'm just asking for some common sense. This package has 3 different
> > levels of details for the world coastline (low, high and full). Are
> > they really needed ? Can't just a low can provided with some pointers
> > to where to get the additional data ?
> >
> > As a matter of facts, I'm kind of opposed to packaging "pure
> > data" (this encloses bible-kjv, anarcho-syndicalism.deb, etc) because
> > for "pure data", packaging is minimal (just dump the file(s) into
> > /usr/share/doc and that's it). This doesn't apply to some reasonably
> > sized "pure data" like /usr/share/dict/words etc...
> >
>
> Ok, so lets create a data section, one that doesn't get mirrored the same as
> the rest of debian. One that does not have source package, or at least not in
> the current form (for the GMT-full coastline, that would be 47MB source and
> 47MB binary). It is OK to create such a section, also required, there is no
> reason why data does not have a right to be as neatly packaged as the rest of
> debian is. Maybe creating a ftp.data.debian.org or something like that would be
> good here.
>
> Friendly,
>
> Sven LUTHER
>
If I can suggests, between providing only the binaries or the sources,
I suggest the source only solution.
Pros:
* Source are more "complete" than binaries (Prisitine source+diff)
* apt-get source -b can handle them quite easily [especially that compilation
it's quite easy for this kind of pacakge ;-]
Cons:
* Take at least three time (source+build package+installation) the place
to install for new install, four times on upgrade!
* No current way to make dselect or even apt dependencies-checker aware
of the binaries file.
The first cons issue is a real one: I really think we should be able to
support people who don't have much disk space but NEEDS to install such
data.
Here are suggestions how we can addressed those cases:
* Add the ability to install those package in place when building.
What I really mean is to make dpkg able to get a package from stream
or let the package do some part of the handling. An example I think
is realisable (*wild guest!* I know near nothing about dpkg internal!)
is to make dpkg handle a new kind of package with no data.tar.gz.
When this happen and the package control contains a X-Source-Only,
dpkg will wait the tar from the output of a extract control script.
The data could them be fetch from the everywhere we want, and even
be autogenerative or used a special compression/encryption mecanism.
This will match the efficiency of dpkg in the aspect of disk-usage.
It can also let it do the unpack step but I don't like this idea:
unpacking is really crucial for conffile, diversion, overwrite error,
etc. I prefer to see dpkg managing all those aspect.
* Make dinstall and dpkg-scanpackages aware of Source-Only packages
so that entries is create in the Package files.
* Make apt (at least) aware of those packages and let it makes a source
-b when install is invoke with one of those packages.
Any comments? I'm surely missing some points given the time is here.
Good night!
--
------------------------------------------------------------------------
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: