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

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-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: