Re: Debian on the Sharp Zaurus/SL-5xxx
On Sun, Jun 16, 2002 at 02:36:27PM -0500, Adam Heath wrote:
> On Sun, 16 Jun 2002, Matt Zimmerman wrote:
>
> > 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 updated this to indicate that this is a planned feature, but not yet
implemented. I seem to recall that you discussed implementing this as a
filter, which I agree is the right approach.
> 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.
I've added this information to dpkg.html.
> * 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
I agree that dpkg is not necessarily the right place for this functionality.
However, I have doubts as to whether it is feasible to maintain the large
number of mount points that would be necessary in order to provide the
necessary granularity. For example, moving /usr to removable media would be
a particularly poor choice, since without /usr, the system is not useful.
The idea would be to spread out the "occasional use" items, while
maintaining core functionality like the GUI and PIM apps. For example,
/var/{cache,lib}/apt and /var/lib/dpkg are only needed when
installing/removing/querying packages. If the media containing them were
ejected, the rest of the system would not notice.
A separate tool to manage this would probably do fine. Noted.
> * 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.
Compression sounds reasonable, especially if it can be done on the fly to
minimize I/O. A post-run hook could probably cooperate with other such
operations, like purging of documentation, unused locale data, etc.
The status and available files on my test system are under 80kb, but they
have a tendency to grow over time due to new packages and the empty
paragraph behaviour.
> * 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.
I'm thinking that it would make a big difference for certain data that the
user really does want. For example, a GIS data package used with a GPS
might include several large files, and there might not be enough disk space
to store two copies of all of them.
I think busybox dpkg may already do something along these lines, but I don't
know what its limitations are (Glenn?).
> * 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.
The more I think about it, this can probably be adequately handled with a
hook to remove them after installation.
> 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.
I think that we can find a sweet spot between current Debian and the iPKG
type distributions that will provide a useful PDA environment while
harnessing the invested effort and infrastructure of Debian/ARM.
So far, CPU has not been an issue for me, a little swap has prevented any
memory shortages, and dealing with disk should just be a matter of expanding
gracefully onto removable media, as they are only getting bigger and
cheaper.
--
- mdz
--
To UNSUBSCRIBE, email to debian-arm-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: