Re: [PATCH] Fix incorrect OS reporting in uname -o
But I'd call such a system BusyBox/Linux instead, since BusyBox is the userspace, regardless of the C library in my opinion. How do you know for sure ? Busybox isn't the only alternative userspace. There are other several, if lesser-known, projects that provide low-level userspace tools. toybox is one. s6-portable-utils + s6-linux-utils is another. And they are certainly not the only ones. In 2000, I have built a server without GNU software just to contradict RMS, who was insisting that I should call my system GNU/Linux instead of Linux. Don't make me build a server without GNU *and* without Busybox just to contradict you. ;) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
On Wed, Sep 18, 2013 at 05:29:48PM +0800, ChenQi wrote: On 09/18/2013 04:47 PM, Pere wrote: On Wed, Sep 18, 2013 at 9:18 AM, Laurent Bercot ska-dietl...@skarnet.org wrote: But I'd call such a system BusyBox/Linux instead, since BusyBox is the userspace, regardless of the C library in my opinion. How do you know for sure ? Because this is Busybox's uname. I think it's possible that there are several uname providers in the system, and busybox is just one of them. Invoking busybox != The userpace is busybox This is why my patch simply proposes removing the incorrect GNU/ part of the uname rather than assuming some other name applies. If others would prefer removing the GNU/ prefix unconditionally, I have no objection, but my intent was to be conservative and merely remove it in cases where there's no justification for calling the system a GNU/Linux system. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] dpkg: copy old control file during --configure
In write_status_file it was assumed that the deb_file_t had a valid
control_file. However, this is not the case when running
--configure. This lead dpkg to write a status-line without any
preceding control information.
This patch uses the control information read from the old status file
if none is found in the deb_file_t struct.
Signed-off-by: Tobias Waldekranz tob...@waldekranz.com
---
archival/dpkg.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/archival/dpkg.c b/archival/dpkg.c
index ed86f33..1b7cc6d 100644
--- a/archival/dpkg.c
+++ b/archival/dpkg.c
@@ -847,9 +847,12 @@ static void write_status_file(deb_file_t **deb_file)
i = 0;
while (deb_file[i] != NULL) {
if (strcmp(package_name,
name_hashtable[package_hashtable[deb_file[i]-package]-name]) == 0) {
+ /* if we're
--configuring no deb file has been read, so copy control from status */
+ char *control_out =
deb_file[i]-control_file ? : control_buffer;
+
/* Write a status file
entry with a modified status */
/* remove trailing \n's
*/
-
write_buffer_no_status(new_status_file, deb_file[i]-control_file);
+
write_buffer_no_status(new_status_file, control_out);
set_status(status_num,
ok, 2);
fprintf(new_status_file, Status: %s\n\n,
name_hashtable[status_hashtable[status_num]-status]);
--
1.8.4.357.g8d83871.dirty
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
On 2013-09-18 04:18, Laurent Bercot wrote: But I'd call such a system BusyBox/Linux instead, since BusyBox is the userspace, regardless of the C library in my opinion. How do you know for sure ? As Pere said, because this is BusyBox uname. If the uname is provided by BusyBox, the userspace is probably BusyBox (just like GNU uname assumes the userspace is GNU). Busybox isn't the only alternative userspace. There are other several, if lesser-known, projects that provide low-level userspace tools. toybox is one. s6-portable-utils + s6-linux-utils is another. And they are certainly not the only ones. Right. But Toybox has its own uname [1][2], so BusyBox uname won't be installed on a Toybox-based system (which of course is not a BusyBox/Linux or GNU/Linux system). Running BusyBox uname on a non-BusyBox system (that is, configuring BusyBox to build only the uname applet and little or nothing else) makes no sense. [1]: http://www.landley.net/toybox/status.html#done [2]: http://www.landley.net/hg/toybox/file/tip/toys/posix/uname.c In 2000, I have built a server without GNU software just to contradict RMS, who was insisting that I should call my system GNU/Linux instead of Linux. Don't make me build a server without GNU *and* without Busybox just to contradict you. ;) If you do, then GNU uname won't be able to call the system GNU/Linux and BusyBox uname won't be able to call it BusyBox/Linux, because it actually won't be either. That doesn't contradict me at all. -- Patrick P. J. McDermott http://www.pehjota.net/ Lead Developer, ProteanOS http://www.proteanos.com/ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
How do you know for sure ? As Pere said, because this is BusyBox uname. That would only prove that the uname implementation is Busybox's. That wouldn't say anything about the rest of the system. Running BusyBox uname on a non-BusyBox system (that is, configuring BusyBox to build only the uname applet and little or nothing else) makes no sense. I guess I make no sense then, because it's exactly what I do. I build my servers from bits and pieces of software, in the original Linux from scratch spirit; I use Busybox when I don't have a better implementation of some functionality. That's the way the OS has become what it is today, that's what free software is about, even if that kind of creativity has of course diminished over the last fifteen-or-so years. The GNU tendency to take over the machine and pretend to provide absolutely everything a user might ever need while disregarding quality smells a bit too much like Microsoft in my opinion; and I'm not particularly happy when people try to push Busybox in that direction too (even if the quality is orders of magnitude better). Call the kernel Linux, even if it's patched, because nobody will build a kernel from bits and pieces: the kernel is monolithic and cathedral-like, and it has a strong identity. But as much as GNU would love to, it's impossible to label userspace. Userspace is a bazaar, even on mainstream distribution you have endless sources of software, and it's fine the way it is. I'm very glad to have Busybox as part of my system, but I really do not want Busybox to claim it IS my system. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
On 2013-09-18 12:38, Laurent Bercot wrote: How do you know for sure ? As Pere said, because this is BusyBox uname. That would only prove that the uname implementation is Busybox's. That wouldn't say anything about the rest of the system. Anyone running BusyBox uname on a non-BusyBox system can easily patch coreutils/uname.c to change the output of `uname -o`. I suggest that BusyBox/Linux be the default otherwise. Perhaps this could be added as an option to Kconfig to obviate a patch. -- Patrick P. J. McDermott http://www.pehjota.net/ Lead Developer, ProteanOS http://www.proteanos.com/ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
On Wed, Sep 18, 2013 at 10:13 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Tue, Sep 17, 2013 at 11:47:55PM -0400, Patrick 'P. J.' McDermott wrote: On 2013-09-17 18:56, Rich Felker wrote: - strcpy(uname_info.os, GNU/Linux); + strcpy(uname_info.os, +#ifdef __GLIBC__ + GNU/ +#endif + Linux); I'd agree that most BusyBox-based systems can hardly be called GNU/Linux, even with glibc. It seems inappropriate to call a system GNU if it has little or no GNU software. Maybe in the case when GNU toolchain was not used to compile the system? But I'd call such a system BusyBox/Linux instead, since BusyBox is the userspace, regardless of the C library in my opinion. My systems have uname from busybox, but I also have ~80 other packages installed, so BusyBox/Linux would be also wrong. Maybe it should be configurable. I don't think BusyBox/Linux is a good idea. And I can't see that making it configurable solves a real issue. Regarding the original patch, not that my opinion matters, but if BusyBox tries to match GNU behaviour in most situations, and Busybox partially derives from GNU source code, then the current behaviour makes sense. -- Pere ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
Hi, On Tue, Sep 17, 2013 at 11:47:55PM -0400, Patrick 'P. J.' McDermott wrote: On 2013-09-17 18:56, Rich Felker wrote: - strcpy(uname_info.os, GNU/Linux); + strcpy(uname_info.os, +#ifdef __GLIBC__ + GNU/ +#endif + Linux); I'd agree that most BusyBox-based systems can hardly be called GNU/Linux, even with glibc. It seems inappropriate to call a system GNU if it has little or no GNU software. Maybe in the case when GNU toolchain was not used to compile the system? But I'd call such a system BusyBox/Linux instead, since BusyBox is the userspace, regardless of the C library in my opinion. My systems have uname from busybox, but I also have ~80 other packages installed, so BusyBox/Linux would be also wrong. Maybe it should be configurable. A. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix incorrect OS reporting in uname -o
On Wednesday 18 September 2013 23:19:51 Pere wrote: On Wed, Sep 18, 2013 at 10:13 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Tue, Sep 17, 2013 at 11:47:55PM -0400, Patrick 'P. J.' McDermott wrote: On 2013-09-17 18:56, Rich Felker wrote: - strcpy(uname_info.os, GNU/Linux); + strcpy(uname_info.os, +#ifdef __GLIBC__ + GNU/ +#endif + Linux); I'd agree that most BusyBox-based systems can hardly be called GNU/Linux, even with glibc. It seems inappropriate to call a system GNU if it has little or no GNU software. Maybe in the case when GNU toolchain was not used to compile the system? But I'd call such a system BusyBox/Linux instead, since BusyBox is the userspace, regardless of the C library in my opinion. My systems have uname from busybox, but I also have ~80 other packages installed, so BusyBox/Linux would be also wrong. Maybe it should be configurable. I don't think BusyBox/Linux is a good idea. And I can't see that making it configurable solves a real issue. Regarding the original patch, not that my opinion matters, but if BusyBox tries to match GNU behaviour in most situations, and Busybox partially derives from GNU source code, then the current behaviour makes sense. -- Pere Hi, GNU/Linux as default value is perfectly in line with the statement on the About section of the busybox website: BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in ___GNU__ fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured __GNU__ cousins; however, the options that are included provide the expected functionality and behave very much like their __GNU__ counterparts. BTW, i suspect that busybox could be compiled and run also on non linux systems so the next step would be to also make the Linux part somehow configurable. A better solution at this point could be to not build the busybox uname applet and use the native one or use a simple wrapper: #!/bin/sh busybox uname $@ | sed 's/GNU\/Linux/MyLibc\/MyKernel/' Ciao, Tito ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
