On Wed, Jun 03, 1998 at 09:31:01AM -0500, Manoj Srivastava wrote:
> >>"Michael" == Michael Bramer <[EMAIL PROTECTED]> writes:
>
> Michael> If the the size information isn't in the debian-package,
> Michael> then i must download two files (NAME-VERSION.deb and
> Michael> NAME-VERSION.size.gz) or
Jules Bean <[EMAIL PROTECTED]> wrote:
> Is du -k not the answer?
du -S, but you need to know how many files are in each directory
to estimate block-size overhead -- assume that each file requires
two thirds of a block of unused space and you won't be too far off.
--
Raul
--
To UNSUBSCRIBE, ema
On Sat, 6 Jun 1998, Raul Miller wrote:
> Joey Hess <[EMAIL PROTECTED]> wrote:
> > How is it possible to check for block sizes with lintian? And what do you
> > expect a maintainer to do if they use a different block size and lintian
> > dislikes that? Reformat?
>
> To deal with block sizes we'll
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> This is getting out of hand, do we really need to consider slack space
> when calculating if the user has enough room to install!?
No, what we mostly need is an estimate.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsub
On Sat, 6 Jun 1998, Raul Miller wrote:
> A brutally simplistic mechanism for representing the data would
> provide a different sizes file for each different block size
> we support. Optimizations are possible but may not be worth the
> effort.
This is getting out of hand, do we really need to c
Raul Miller <[EMAIL PROTECTED]> wrote:
> To deal with block sizes we'll need to abandon (or upgrade) du.
Argh.. please ignore this sentence, it makes no sense.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Joey Hess <[EMAIL PROTECTED]> wrote:
> How is it possible to check for block sizes with lintian? And what do you
> expect a maintainer to do if they use a different block size and lintian
> dislikes that? Reformat?
To deal with block sizes we'll need to abandon (or upgrade) du.
To find out what b
Manoj Srivastava wrote:
> Brederlow> The size file should be generated by the server. Here are
> Brederlow> the reasons:
>
> I am (perhaps unnecessarily) worried about time requirements
Considering that we plan to eventually have lintian run automatically on
packages before they get move
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hi,
> >>"Brederlow" == Brederlow <[EMAIL PROTECTED]> writes:
>
> Brederlow> I mean, that when a package is installed, that the
> Brederlow> recorded du tree (which is needed to calculate the size
> Brederlow> increase/decrease for updates) could
Hi,
>>"Brederlow" == Brederlow <[EMAIL PROTECTED]> writes:
Brederlow> I mean, that when a package is installed, that the
Brederlow> recorded du tree (which is needed to calculate the size
Brederlow> increase/decrease for updates) could be trimmed to what
Brederlow> the users system reflects.
Hi,
>>"Michael" == Michael Bramer <[EMAIL PROTECTED]> writes:
>> a) the data is harder to manipulate: as a separate file, dinstall
>> just has to rename the file to a cache area, and use zcat and
>> echo to generate the master sizes.gz file.
>>
>> As a control file, dinstall has to unpack th
Hi,
>>"Brederlow" == Brederlow <[EMAIL PROTECTED]> writes:
Brederlow> The size file should be generated by the server. Here are
Brederlow> the reasons:
I am (perhaps unnecessarily) worried about time requirements
Brederlow> 1. The upload should be unpacked to check if the gz is not
On Wed, Jun 03, 1998 at 02:23:02PM +0200, Brederlow wrote:
> Michael Bramer <[EMAIL PROTECTED]> writes:
> > [1 ]
> > On Wed, Jun 03, 1998 at 02:25:39AM -0500, Manoj Srivastava wrote:
> > dinstall get the size.gz file from the .deb file (ar -x) and put it to the
> > cache area. I don't see the diff
Michael Bramer <[EMAIL PROTECTED]> writes:
> [1 ]
> On Wed, Jun 03, 1998 at 02:25:39AM -0500, Manoj Srivastava wrote:
> > Hi,
> > >>"Michael" == Michael Bramer <[EMAIL PROTECTED]> writes:
> >
> > Michael> I think the right place is in the *.deb-file. In the
> > Michael> control-file (like the
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hi,
> 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 th
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hi,
> >>"Brederlow" == Brederlow <[EMAIL PROTECTED]> writes:
>
> Brederlow> Would that already be a correct Packages file or would dpkg and
> Brederlow> similar scream about wrong entries? Could old dpkg's handle the
> new
> Brederlow> entries?
On Wed, Jun 03, 1998 at 02:25:39AM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Michael" == Michael Bramer <[EMAIL PROTECTED]> writes:
>
> Michael> I think the right place is in the *.deb-file. In the
> Michael> control-file (like the description) or as new file in *.deb.
>
> Why do you thi
Hi,
>>"Michael" == Michael Bramer <[EMAIL PROTECTED]> writes:
Michael> I think the right place is in the *.deb-file. In the
Michael> control-file (like the description) or as new file in *.deb.
Why do you think so? You don't give any reasons whatsoever, so
this is not a technical stat
On Tue, Jun 02, 1998 at 11:55:06AM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Charles" == Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:
>
> Charles> Manoj Srivastava writes:
>
> Charles> $ gzip -l Sizes.hamm.*.gz
> Charles> compressed uncompr. ratio uncompressed_name
> Charles> 1
Hi,
>>"Charles" == Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:
Charles> Manoj Srivastava writes:
Charles> $ gzip -l Sizes.hamm.*.gz
Charles> compressed uncompr. ratio uncompressed_name
Charles> 105201795450 86.7% Sizes.hamm.contrib
Charles> 66294402982 83.5% S
Manoj Srivastava writes:
>I think we should look at the possibility of not including the
> information in either the Packages file nor the available file. The
> Du files hsould be separately kept on the archives, and they maybe
> compressed with gzip (bzip2?); and downloaded and kept in
> /
In message <[EMAIL PROTECTED]>,
Brederlow writes:
>
>Would that already be a correct Packages file or would dpkg and
>similar scream about wrong entries? Could old dpkg's handle the new
>entries?
It seems to work for me. Any entries that are not recognised are ignored
or passed through unchanged.
22 matches
Mail list logo
