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

Re: multiarch support and dpkg 2.0 design document



Matt Wilson <msw@rpath.com> writes:

> On Fri, May 19, 2006 at 12:46:13PM +0200, Goswin von Brederlow wrote:
>>
>> >> The current dpkg database counts for less than 0.1% of the entire used
>> >> disk space of a typical Debian system.  Even with the new meta-data, I
>> >
>> > I think it makes more sense to measure database size as compared to
>> > the size of managed files.  Conary manages 4.62 GiB on my system.  We
>> > use a sqlite database that's 126 MiB.  I have a 60 GB hard drive on my
>> > system, so that's roughly 0.2%.
>> 
>> It makes no sense to compare the database size to a typical
>> system. Typical systems have so much diskspace that they just don't
>> care anyway.
>
> That's what I was attempting to say.  Almost all of the 60 GB on my
> disc are "used."  The metric should be database size given the data
> under package management.
>
>> The problem is with small systems. Your mips router, your arm pda and
>> so on. With a 256-512MB disk an 126MB databse is quite unacceptable.
>> Even now dpkg + apt meta data can make up half of the systems
>> diskspace.
>
> No doubt a 126 MiB database is too big for a PDA - but it will have
> far, far less data under package management.  I don't know how small a
> Conary database would be in this case, but it certainly won't be 126
> MiB.
>
> I'm not sure how feasible it will be to have a good database that
> meets the needs for both big systems and embedded systems.  ipkg seems
> to be a sufficient package management solution for the extremely small
> systems...

One problem is that you have a static and a dynamic part of meta data
for dpkg:

Static: (size with small sources.list, sarge main deb + source)
/var/lib/apt/lists/*     (18 MiB)
/var/cache/apt/*.bin     (10 MiB)
/var/lib/dpkg/available* (24 MiB) [if you ever updated that, e.g. run dselect]

Dynamic: (size on my desktop)
/var/lib/dpkg/status*    ( 4 MiB)
/var/lib/dpkg/info/*     (30 MiB)

As you can see even for a desktop system the dynamic parts of dpkg
that vary with the number of installed packages is still less than the
static parts that just list available packages.


A lot can be done for small systems (+ chroots, vserver, xenU domains)
just by generating an alternative Packages file listing only packages
intresting for them and omitting package long desctiptions. Most of
the meta data is description:

cat /var/lib/apt/lists/*{Sources,Packages} | grep-dctrl -v Description | wc
 162890  458086 5854991

Also having /var/lib/apt/lists/*, /var/cache/apt/*.bin and
/var/lib/dpkg/available* (that includes a full backup) means most
information is in quadruplicate. I bet ipkg does that more eficient.

root@OpenWrt:~# du -h /usr/lib/ipkg/
14.5k   /usr/lib/ipkg/info
0       /usr/lib/ipkg/lists
15.0k   /usr/lib/ipkg
root@OpenWrt:~# du -h /rom/usr/lib/ipkg/      
15.5k   /rom/usr/lib/ipkg/info
18.5k   /rom/usr/lib/ipkg

My OpenWRT has no lists for updates so I can't say how efficient is
there. But the info dir is a lot smaller. The status file only 2K and
no available file. Comapring the two (ignoring lists) I get a factor
of 1000 in size. Thats quite impressive.

Having a slim minimal system and a full blown database system is
certainly not out of the question.

> Cheers,
>
> Matt

MfG
        Goswin



Reply to: