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

Re: On adding size info to Packages files [very long]



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?

	manoj	
-- 
 "I admire men of character, and I judge character not by how men deal
 with their superiors, but mostly how they deal with their
 subordinates, and that, to me, is where you find out what the
 character of a man is." General Norman Schwarzkopf
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: