cc'd to debian-dpkg, for comment. On Sun, 16 Jun 2002, Matt Zimmerman wrote:
> On Sun, Jun 16, 2002 at 03:34:30AM -0500, Adam Heath wrote: > > > However, I don't generally tinker with hardware(I'm a programmer). > > However, I am a dpkg developer, so any patches it (archtable, mostly) can > > be integrated quickly. > > I have dreamed up some possible dpkg enhancements which could make life > easier for a PDA type environment. I've put them up at: > > http://people.debian.org/~mdz/zaurus/dpkg.html > > I'd be interested to hear your opinions about whether they would indeed be > useful, and how difficult they would be to implement. * Exclude arbitrary filesets from being unpacked This is already being implemented (or implemented) and will be available relatively soon I've reordered the list that is at the above url, to make sertain * Strip down status file Exclusion of Description, Priority, Section, and possibly others, would save a significant amount of space in the package database 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. As to the large fields, we will probably do that as well. * 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. mount /dev/foo /mount/foo mount /mount/foo/usr /usr <-- bind mount * Optionally disable available-old and status-old backups Disk space and speed savings Hmm. Interesting point. How about having dpkg also compress them, in preference to just getting rid of them? Also, a post-run hook could check the return value of dpkg, and if there was no error, could remove the files. * 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. Well, the amount of files extracted will be smaller, due to your first request. And I would hope that you always have some storage space left over. However, We'll take it into consideration. * 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. md5sums will be calculated during unpack, in the future. shlibs are a development need, so it might be possible to exclude them without harm. == What you are really dealing with, is not a system that is a workstation, but a system that is embedded. Certain things just don't make sense on this. udebs are the right approach, but even they assume certain things, about the size(memory, disk, cpu) of the target system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
