Re: Debian on the Sharp Zaurus/SL-5xxx
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 debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: