@Clarence: I     agree that dpkg should be able to handle this. Would "REPLACE: busybox(##version##)"  be needed instead of PROVIDES? Because busybox is an essential package, you can't uninstall the existing one to reinstall the new one, which makes me suspect that the new one would need to REPLACE the old one.
<br> <br>BTW, I found the &quot;missing&quot; busybox-1.6.1 package&nbsp;in&nbsp;the&nbsp;maemo&nbsp;repos -- brain meltdown on my part.<br><br><div><span class="gmail_quote">On 1/1/08, <b class="gmail_sendername">Clarence Risher</b> &lt;<a href="mailto:sparr0@gmail.com">
sparr0@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
apt can handle a situation like this just fine, and dpkg can too with<br>a little work, and does so for many types of libraries and binaries<br>already in debian and ubuntu.&nbsp;&nbsp;I believe you just make the new package<br>PROVIDES the same things as the old package, with the same version
<br>number, and CONFLICTS the old package.<br><br>On Jan 1, 2008 12:00 PM, Damien Moore &lt;<a href="mailto:damienlmoore@gmail.com">damienlmoore@gmail.com</a>&gt; wrote:<br>&gt; I&#39;d like to bring up the busybox applet selection issue again. This
<br>&gt; was previously discussed here:<br>&gt;<br>&gt; <a href="http://lists.maemo.org/pipermail//maemo-developers/2007-April/009738.html">http://lists.maemo.org/pipermail//maemo-developers/2007-April/009738.html</a><br>
&gt;<br>&gt; with associated bug here:<br>&gt;<br>&gt; <a href="https://bugs.maemo.org/show_bug.cgi?id=989">https://bugs.maemo.org/show_bug.cgi?id=989</a><br>&gt;<br>&gt; the bug was marked WONTFIX<br>&gt;<br>&gt; Eero Tamminen&#39;s resolution was to not add any additional applets to
<br>&gt; BusyBox because in his opinion those needs can best be met by creating<br>&gt; full versions of the tools in separate packages. I don&#39;t think this is<br>&gt; a good idea because it creates a proliferation of unnecessarily
<br>&gt; bloated packages with the attendant problems of maintaining multiple<br>&gt; packages (keeping in mind that the target hardware is a capacity<br>&gt; constrained tablet). The benefit of busybox is that most appplets add
<br>&gt; just a few kb to the binary size and all of them sit inside a single<br>&gt; binary.<br>&gt;<br>&gt; My proposal is to create an alternative &quot;essential&quot; busybox package<br>&gt; that optionally replaces the default busybox, say &quot;busybox-max&quot;.
<br>&gt; busybox-max would be built with many more applets (more of the archive<br>&gt; tools, more shell support (e.g. longer command histories and color<br>&gt; coded ls), more networking tools etc. This package would not be
<br>&gt; installed by default, it would just be an optional package for<br>&gt; developers/hackers. I don&#39;t know how well dpkg would handle the<br>&gt; package replacement but it is worth exploring.<br>&gt;<br></blockquote>
</div><br>