Re: Debian on the Sharp Zaurus/SL-5xxx
On Sun, Jun 16, 2002 at 05:28:55PM +0100, Philip Blundell wrote:
> On Sun, 2002-06-16 at 17:19, Matt Zimmerman wrote:
> > Yes, there are quite a few of these. I hardly see the point, though, of
> > repackaging a ton of software in 'ipkg' format when we already have a
> > ton of working infrastructure and existing packages for debs. Frankly,
> > I can't imagine why anyone would want to try to duplicate the effort
> > that has been put into Debian/ARM.
>
> Agreed. A lot of the ipkgs are generated semi-mechanically from binary
> .deb packages, rather than directly from source, but it's still a fairly
> labour-intensive and gruesome process.
Yes, some of the materials I have been reading seem to imply that this kind
of semi-automatic conversion is taking place. Some projects are in effect
building a BSD-ports-like system on top of the Debian archive, possibly
without realizing that Debian is already such a layer, which exists
precisely in order to provide this kind of additional value.
> Apparently, the original reason why the familiar people started down the
> ipkg route was that they didn't like the way .deb archives used two
> different storage formats internally, "ar" for the control stuff and "tar"
> for the data, meaning you needed a lot of code to handle the package
> files. But since busybox now includes a functioning dpkg implementation
> with internal ar, this is now something of a moot point.
Given the wealth of existing, open, well-tested code for dealing with the ar
and tar formats (including dpkg-deb itself), I don't understand why this
would present a significant difficulty.
It is worth noting that the version of busybox which ships on the Zaurus is
somewhat broken in this respect. It contains an ar -> busybox symlink, but
the busybox binary does not have ar support. It is unclear why this is the
case.
> The other issue is obviously that .deb packages tend to install a load of
> crud that you don't want on a device that only has 16MB of storage, like
> documentation, and this was getting stripped out in the deb -> ipkg
> conversion process. But I think the way to solve that is using our
> existing "udeb" technology, and persuading maintainers to start generating
> small binary packages for portable use.
Another approach is to add functionality to dpkg to enable the exclusion of
certain files. This is already in the works, and depending on the
implementation (which I haven't examined or asked about yet), it may even be
possible for packages to provide information about which portions of the
package can be safely excluded, effectively providing installation profiles
for several stripped-down configurations.
--
- mdz
--
To UNSUBSCRIBE, email to debian-arm-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: