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

Re: On adding size info to Packages files

On Tue, Jun 02, 1998 at 11:55:06AM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Charles" == Charles Briscoe-Smith <cpbs@debian.org> writes:
>  Charles> Manoj Srivastava writes:
>  Charles>   $ gzip -l Sizes.hamm.*.gz
>  Charles>   compressed  uncompr. ratio uncompressed_name
>  Charles>      105201    795450  86.7% Sizes.hamm.contrib
>  Charles>       66294    402982  83.5% Sizes.hamm.main
>  Charles>       11446     63766  82.0% Sizes.hamm.non-free
>  Charles>      182941   1262198  85.5% (totals)
>  Charles> Looks reasonable...  In practice, this information is only
>  Charles> going to be used while installing packages, and 180K isn't
>  Charles> much anyway.  We could save far more space by compressing
>  Charles> the available, available-old, status and status-old files
>  Charles> (2.5Mb on my system).
>  Manoj> We have conflicting data here. Mrvn says that the total du
>  Manoj> data is only 76k. Charles says that the data is about 400k
>  Manoj> (which is way more in line with my off the cuff calculations).
>  Charles> The 400K was for normal hamm Packages files with additional
>  Charles> Du data added to it.  That makes my numbers far closer to
>  Charles> Mrvn's.  Also, weren't Mrvn's figures were for main only?
> 	I stand corrected. Seems like my off the cuff estimates were
>  off a bit. 
>  Manoj> I also would strongly advocate *NOT* stuffing this data into
>  Manoj> the Packages or the Available files, but keeping this apart on the
>  Manoj> archive and when downloaded on the users disk.
>  Charles> I'm now with you on this one.  Given the sizes involved, I
>  Charles> don't think we even need to go to the trouble of generating
>  Charles> the "top N levels" versions.  Using this would make it
>  Charles> difficult to take symlinks into account.
> 	Well, now all we have to do is decide how this information
>  should be gathered. Does the package maintainer stick it into the deb
>  file? Should one upload the file separately (possibly modifying
>  dpkg-genchanges to also pgp stamp the sizes file, though I think a
>  hacked sizes file is not a major security breach, as long as the
>  package itself is intact).
> 	If we go with a separate file kernel-package_4.08-1_i386.sizes.gz;
>  then all we need is a modified dupload, and a modification of Guys
>  script to handle the sizes file, even stashing it some place on the
>  archive (debian/dists/unstable/sizes-i386/misc/kernel-package_4.08-1.gz)
>  though that location maybe suboptimal cause of the mirrors. dinsall
>  can just zcat the files sa needed.
> 	Comments?

I think the right place is in the *.deb-file.
In the control-file (like the description) or as new file in *.deb.

So we must modified buildpackage. 

But I thinkt also, that we should change Guys script. It should make a
Package-size[.gz] file (like Packages[.gz] on the ftp-server) from old 
and new packages. Dselect or apt can download it and calulate the 
packagesize without download the deb-packages.



Attachment: pgptZcjhPli6C.pgp
Description: PGP signature

Reply to: