Re: Debian on the Sharp Zaurus/SL-5xxx
On Mon, Jun 17, 2002 at 12:26:18PM +0200, Wichert Akkerman wrote:
> Previously Matt Zimmerman wrote:
> > 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
Yes, this is how I thought of it as well.
> 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).
But this should only happen if this feature is actually in use, correct? So
it won't penalize anyone who isn't using it.
Even on the Zaurus, with a relatively slow processor, dpkg seems to be I/O
bound when unpacking to flash (which is even slower).
> The first requires a change in the package format
> since version 2 of the deb format does not include the necessary
> information.
Wouldn't it be possible to include a new control file containing the
necessary information?
/usr/share/doc/foo doc
/usr/share/foo/help/index.html doc
> > 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.
Noted.
> > 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.
I understand why dpkg does this, but on a system where normal operating
conditions are such that there may only be a few megabytes of free space,
the tradeoff may be worth it.
Apparently, busybox dpkg can be used if necessary, so I'm going to drop this
one.
> 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.
I can just remove them after dpkg runs.
> > 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.
I want to avoid basing this mechanism on bind mounts because the number of
mount points could grow very large, and it is not as easy to support
transparent card removal/insertion. Insertion of the card would have to
trigger a certain set of bind mounts, and that data must be stored and
maintained somewhere, and managed by some magic. With symlinks, all of the
information is explicit in the filesystem and easy to understand.
I have been experimenting to see how dpkg will deal with the symlink
approach, and I have a couple of notes:
- if there is a symlink x -> y, and dpkg wants to create the directory x,
all of the parents of y must exist (dpkg does not seem to create them, and
fails). This is only a minor inconvenience; I will probably provide a
tool which will set up links to either the CF or SD card, and create the
necessary directories.
- when removing a package, the symlink is removed, and the directory at the
destination remains. This doesn't particularly bother me, either, but I
am wondering if this is intentional.
--
- mdz
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: