Hi,
ext Clarence Risher wrote:
On Jan 2, 2008 7:04 AM, Eero Tamminen [EMAIL PROTECTED] wrote:
As to bloatedness, there's an apt-hook installed on the device that
removes the extra docs when a package is installed (at least man info
pages). Developer could also run something like Debian's
On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote:
This is fairly unlikely case, but IMHO reason enough not to have two
busybox versions with different set of tools. Main thing is that the
developer can get the required tool, not whether it's in Busybox
I think.
I agree that the important thing
ext Damien Moore [EMAIL PROTECTED] writes:
https://bugs.maemo.org/show_bug.cgi?id=989
the bug was marked WONTFIX
Eero Tamminen's resolution was to not add any additional applets to
BusyBox because in his opinion those needs can best be met by creating
full versions of the tools in separate
Hi,
I think it's good you raised this issue as it needs some discussion.
Busybox is a base part of maemo, but we don't yet list it as an official
SDK API although most packages need/use it when they are installed.
ext Damien Moore wrote:
I'd like to bring up the busybox applet selection issue
On 1/1/08, sebastian maemo [EMAIL PROTECTED] wrote:
What would happen with an order like this?...
# apt-get -o APT::Force-LoopBreak=1 install busybox replacement
Maybe a broken system?
I would think almost certainly a broken system. I think dpkg scripts depend
on busybox tools being there, so
On 1/2/08, Kalle Valo [EMAIL PROTECTED] wrote:
I have to agree with Eero here. It's much more useful to have the
original tools available instead of (too) simple busybox variants.
what I'm suggesting would be an optional package that, if set up correctly,
won't break anything (but will block
ext Damien Moore [EMAIL PROTECTED] writes:
On 1/2/08, Kalle Valo [EMAIL PROTECTED] wrote:
I have to agree with Eero here. It's much more useful to have the
original tools available instead of (too) simple busybox variants.
what I'm suggesting would be an optional package that, if set up
On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote:
The maintenance wouldn't be a problem. Then those packages can come
directly from Debian. Also, then trying to install a properly working
replacement for a buggy/incomplete Busybox functionality doesn't mean
that one would need to remove first
Hi,
ext Damien Moore wrote:
On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote:
The maintenance wouldn't be a problem. Then those packages can come
directly from Debian. Also, then trying to install a properly working
replacement for a buggy/incomplete Busybox functionality doesn't mean
that
On Jan 2, 2008 7:04 AM, Eero Tamminen [EMAIL PROTECTED] wrote:
As to bloatedness, there's an apt-hook installed on the device that
removes the extra docs when a package is installed (at least man info
pages). Developer could also run something like Debian's localepurge.
Most of the package
I'd like to bring up the busybox applet selection issue again. This
was previously discussed here:
http://lists.maemo.org/pipermail//maemo-developers/2007-April/009738.html
with associated bug here:
https://bugs.maemo.org/show_bug.cgi?id=989
the bug was marked WONTFIX
Eero Tamminen's
@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
2008/1/2, Damien Moore [EMAIL PROTECTED]:
@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
13 matches
Mail list logo
