On Wed, Aug 11, 2010 at 05:32:24PM +0100, Wookey wrote:
>
> Making sure that only repos that are actually needed on the target are
> listed can help. Does it need src repos? Does it need
> universe/multiverse? leaving those out makes a huge difference.
atm, we dont have deb-src lines from what i
+++ Christian Robottom Reis [2010-08-05 22:28 -0300]:
> Hi there!
>
> I unpacked our minimal release image and ran an xdiskusage on it,
> mostly to see what we're shipping -- and I was surprised to see that a
> fourth of the image is actually apt package caches and lists.
This is typical for
Hello Dave,
Dave Martin [2010-08-09 9:48 +0100]:
> Fortunately fragmentation is not a problem: tar --delete squashes the
> deleted entry out of the file by rewriting the entire file contents
> from the point where the deletion occurred ;) Of course, that could
> be a bit slow, especially if you
Hello Dave,
Dave Martin [2010-08-09 10:47 +0100]:
> Hence my thought of having a tarball per package. I'm still a bit
> worried about a post-unpack hook changing the package files to be
> different from dpkg's file list for the package -- that could cause
> safety problems. Is there a way to tel
Christian Robottom Reis [2010-08-06 10:30 -0300]:
> By touch I think you mean install, upgrade or remove, and of these I
> guess upgrade is the more common case; do you think it is?
install and upgrade are the common ones, right.
> Would the overhead be significant even if the tarball wasn't comp
On Mon, Aug 9, 2010 at 10:36 AM, Martin Pitt wrote:
> Hello Dave,
[...]
> Ah, right. I take it that rules out having one big tarball for
> /usr/share/doc/ then?
Hence my thought of having a tarball per package. I'm still a bit
worried about a post-unpack hook changing the package files to be
d
On Sun, Aug 8, 2010 at 6:50 PM, Martin Pitt wrote:
[...]
> As far as I know you can append files; I'm not sure about "inline"
> deletion, but even if it would exist, then over time (i. e. upgrades)
> you would dramatically fragment the file, which reduces or even
> reverts the initial space savi
On Thu, Aug 05, 2010, Christian Robottom Reis wrote:
> I was surprised to see that a
> fourth of the image is actually apt package caches and lists.
Yup, Martin Pitt worked on some APT patches to allow keeping these
compressed in the local disk.
--
Loïc
On Fri, Aug 06, 2010 at 05:38:56PM +0100, Dave Martin wrote:
> > Would the overhead be significant even if the tarball wasn't compressed?
> > I don't understand enough about tar's concatenate and delete performance
> > to risk a guess.
>
> tar's default internal blocksize is 512 bytes, so there wo
On Fri, Aug 6, 2010 at 3:15 PM, Michael Vogt wrote:
> You have the following options to make the on-disk file size smaller:
>
> * keep them compressed on disk (needs apt in maverick), you need to set
> """
> Acquire::GzipIndexes "true";
> """
> in /etc/apt/apt.conf.d/10keepcompressed
>
>
On Fri, Aug 6, 2010 at 2:30 PM, Christian Robottom Reis wrote:
> By touch I think you mean install, upgrade or remove, and of these I
> guess upgrade is the more common case; do you think it is?
I think you're right. This hits the end user more than first-time
installation - install and remove
On Fri, Aug 06, 2010 at 12:05:25PM +0200, Alexander Sack wrote:
> On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin wrote:
> > On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack wrote:
> > > On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis > >> Hi there!
> > >>
> > >>I unpacked our minimal rel
On Fri, Aug 06, 2010 at 02:16:00PM +0200, Martin Pitt wrote:
> Hello all,
>
> Alexander Sack [2010-08-06 12:15 +0200]:
> > > If we have to keep /usr/share/doc/ (for copyright notices and so on),
> > > maybe it would be feasible to replace each /usr/share/doc//
> > > with a tarball? This would eli
On Fri, Aug 06, 2010 at 10:57:21AM +0100, Dave Martin wrote:
> We could remove these files, but I agree it may be a false
> optimisation: the size of the release filesystem is no longer
> representative of the steady-state size of the filesystem when it's in
> use in this case.
Well, I think that
Hello all,
Alexander Sack [2010-08-06 12:15 +0200]:
> > If we have to keep /usr/share/doc/ (for copyright notices and so on),
> > maybe it would be feasible to replace each /usr/share/doc//
> > with a tarball? This would eliminate most of the overhead as well as
> > making the actual data smaller
Hello,
Dave Martin [2010-08-06 13:35 +0100]:
> Just to clarify my meaning--- I expected to have a tarball per
> package, not one massive tarball for the whole system... the cost of
> maintaining the latter would certainly get very unpleasant for people.
Hm, but then you wouldn't save a lot -- you
On Fri, Aug 6, 2010 at 11:16 AM, Zygmunt Bazyli Krynicki
wrote:
> On Fri, 2010-08-06 at 12:05 +0200, Alexander Sack wrote:
>> Out of interest, does anyone know why dpkg/apt never migrated
>> from the
>> "massive sequential text file" approach to something more
>> da
On Fri, Aug 6, 2010 at 1:16 PM, Martin Pitt wrote:
> Hello all,
>
> Alexander Sack [2010-08-06 12:15 +0200]:
>> > If we have to keep /usr/share/doc/ (for copyright notices and so on),
>> > maybe it would be feasible to replace each /usr/share/doc//
>> > with a tarball? This would eliminate most o
On Fri, 2010-08-06 at 12:05 +0200, Alexander Sack wrote:
> Out of interest, does anyone know why dpkg/apt never migrated
> from the
> "massive sequential text file" approach to something more
> database-oriented? I've often thought that the current
> system'
On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin wrote:
> On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack wrote:>>
> * stripping /usr/share/doc out (but everybody knew that)
>
>
> > ack. we plan to do that using pitti's dpkg improvements; last time they
> > didn't land
> > in the archive yet, but I
On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin wrote:
> On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack wrote:
> > Hi,
> >
> > On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis >
> > wrote:
> >>
> >> Hi there!
> >>
> >>I unpacked our minimal release image and ran an xdiskusage on it,
> >
On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack wrote:
> Hi,
>
> On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis
> wrote:
>>
>> Hi there!
>>
>> I unpacked our minimal release image and ran an xdiskusage on it,
>> mostly to see what we're shipping -- and I was surprised to see that a
>>
Hi,
On Fri, Aug 6, 2010 at 3:28 AM, Christian Robottom Reis wrote:
> Hi there!
>
>I unpacked our minimal release image and ran an xdiskusage on it,
> mostly to see what we're shipping -- and I was surprised to see that a
> fourth of the image is actually apt package caches and lists. Can we
Hi there!
I unpacked our minimal release image and ran an xdiskusage on it,
mostly to see what we're shipping -- and I was surprised to see that a
fourth of the image is actually apt package caches and lists. Can we
put into the image generation script something to strip them out before
gener
24 matches
Mail list logo
