Re: Debian on the Sharp Zaurus/SL-5xxx
Previously Matt Zimmerman wrote:
> To save you the trouble of cutting and pasting:
Thanks. Adam already went over most of them but I'll do so again anyway :)
> Exclude arbitrary filesets from being unpacked
> This is already planned for a future dpkg release. Ideally, it would be
> possible for binary packages themselves to specify some information about what
> can be safely excluded.
This is actually two seperate items:
* flag to not install files of a certain type (like documentation, or
translations)
* option to exclude bits of filesystem hierarchy from being modified
The second one is easy (but will slow down dpkg a lot unfortunately
since it will need to do string comparisons or regexp matching on every
file it touches). The first requires a change in the package format
since version 2 of the deb format does not include the necessary
information.
> Strip down status file
> Exclusion of Description, Priority, Section, and possibly others, would save a
> significant amount of space in the package database. Adam Heath: There are
> plans to do this. If you look at status, there are empty package paragraphs.
> dselect uses these, and they polute the dpkg runtime memory. We have plans to
> remove these entries.
What Adam said :). Basically we want to split the status file into 2 or
3 files: one with just the essential status information (package name,
version, status, dependencies ) and one with all the other data
(description, maintainer, bug info, etc.). Since we already put dselect
into its own package it might makes sense to move some of the info dselect
uses into a third file.
> Optionally disable or compress available-old and status-old backups
> Disk space and speed savings
This is not a speed savings. Those -old files are simply the untouched
originals renamed.
> Optionally unpack files in-place
> Dangerous, but would provide significant space savings for upgrades. Might it
> be better to remove (but not purge) and then install the new version? Doing
> this frequently could provoke lurking bugs in maintainer scripts.
The problem with this you need to have all the original files available
in order to do error recovery. When a package fails to install dpkg will
remove the new files and put the old files back on place. I am very
hestitant to make any change in dpkg that makes error recovery less
robust so I might refuse to make this change.
> Exclusion of certain control files (?)
> md5sums and shlibs could be excluded in most environments. templates also tends
> to be quite large, but I don't know what can be done about that. Exclude
> certain translations? It might be more effective to use a filesystem which can
> effectively store many small files, as most of the cost seems to be from large
> block sizes. Probably done most effectively with a separate tool.
As Adam mentions md5sums should not be in packages anyway, dpkg will
generate checksums when installing a package in a future version. Those
checksums will still need to be stored somewhere though.
> Automated slicing of packages across different filesystems
> For example, allow the user to say "for package X, place hierarchy Y at
> location Z instead, and symlink Y -> Z". This would allow larger packages,
> which might not even be able to be unpacked in internal storage, to gracefully
> flow onto removable media. This probably belongs in a separate tool.
Indeed. With symlinks and bind mounts you can do this so that dpkg does
not need to know (or notice) how you divide things over your physical
storage.
Wichert.
--
_________________________________________________________________
/wichert@wiggy.net This space intentionally left occupied \
| wichert@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: