В общем, вопрос о выборе между простотой и 100% правильностью, а также о фразе "LFS is not a distro".
Linux From Scratch выпускает книжку о самомтоятельной сборке Linux: http://www.linuxfromscratch.org/lfs/view/development/ . Для тех, кто справился и хочет продвинуться дальше, есть BLFS: http://www.linuxfromscratch.org/blfs/view/svn/ . Есть еще такой человек, Greg Schafer, который имеет (вроде бы обоснованные) претензии к методу получения самосогласованной цепочки инструментов компиляции в LFS и к некоторым другим (в том числе организационным) моментам. Он выпустил форк LFS: http://www.diy-linux.org/x86-reference-build/ .
В связи с тем, что набор применяемых исправлений в LFS и DIY различается, я послал Greg'у уведомление следующего содержания:
---- I want to know your opinion on the following patches that are in various sorts of LFS but not in DIY Linux. Please verify each one, because there may still be a case of bad smoke.
1) glibc-2.4 patches in CLFS: http://cross-lfs.org/files/patches/1.0.0rc3/glibc-2.4-iconv_fix-1.patch and http://cross-lfs.org/files/patches/1.0.0rc3/glibc-2.4-localedef_segfault-1.patch. Since I have never built a system with glibc-2.4, I can't tell you direct facts. Some indirect ones are that the headers of those patches mention that the bugs are not LFS-specific (and even provide links), and that you don't apply those patches. Are you able to reproduce those bugs?
2) glibc-2.3.6 Linux Types Patch: relevant for compiling Xorg. Without the patch, some versions of Xorg (including 6.9) give compilation errors in agp-related file.
3) Gawk "invalid free" patch, incorrectly referenced as "segfault" by LFS. The bug is triggered by "awk '{}' no_such_file".
4) Gawk, #define HAVE_LANGINFO_CODESET 1 in config.h. Relevant in the vi_VN locale, because this locale uses the UTF-8 character set, but its name doesn't end in "UTF-8". Without the define, gawk fails to recognize this as a UTF-8 locale and treat it as such. But DIY doesn't support UTF-8, so you can ignore this.
5) GRUB Disk Geometry Patch: I don't know the exact description of the problem. Maybe the patch is not really good.
6) Gzip Security Patch: Unfortunately, I have no testcase, but the patch has CVE references.
7) Kbd Backspace/Delete Fix Patch: This makes all keymaps consistent WRT their Backspace/Delete handling. Without the patch, with some keymaps like "ru" and "no-latin1", Ctrl+H doesn't bring up help in Emacs.
8) Module-init-tools Patch from http://www.linuxfromscratch.org/patches/lfs/development/module-init-tools-3.2...: required for udev to autodetect some USB storage devices. The problem (and a reproducible tescase) is described fully at http://bugs.debian.org/350915
9) Tar security fix (malformed tar archive can make tar segfault)
10) Tar sparse file handling fix (please help the Linux-NTFS project by not providing a broken tar, see http://lists.gnu.org/archive/html/bug-tar/2005-03/msg00004.html)
11) Shadow, reencoding of manual pages from UTF-8 to 8-bit encodings. The fact is that Man passes the "-Tlatin1" option to Groff by default, and that implies that manual pages should be stored in language-specific 8-bit encodings on disk. This is not the case with the current DIY. The result is that e.g. Russian manual pages become a mess of unreadable characters.
12) You don't pass any "lang" argument to Man-1.6d. This causes the message catalogs not to be installed, but the relevant code is still compiled into Man. The result is that a pointless message about NLSPATH is printed in non-English locales. Please pass "+lang none" to disable translation of messages completely and thus avoid this meaningless warning (this is also needed if you plan to support UTF-8 with Man, as Man doesn't correctly reencode translated messages).
13) Vim-7.0 patch about the manual pages. This is necessary in order for "man vim" to display the Russian manual page of Vim in Russian locale. Man simply doesn't search in /usr/share/man/ru.KOI8-R.
----
Получил ответ:
---- On Sun, Jul 30, 2006 at 05:55:09PM +0600, Alexander E. Patrakov wrote:
> > I want to know your opinion on the following patches that are in various > > sorts of LFS but not in DIY Linux. Please verify each one, because there > > may still be a case of bad smoke.
Alex, DIY clearly has different goals to LFS which explains a lot. In particular, DIY has a "minimal patches" policy and (unfortunately) pays no attention to i18n and UTF8. DIY also takes a different view on security patches (albeit not yet documented but on my TODO). I think the LFS mentality of patching every known corner case is absurd. You might as well just run a distro. Your average build-from-source'r just wants a functioning system. Sure, if something doesn't work that matters to *them*, they just go and find the patch and apply it.
> > 1) glibc-2.4 patches in CLFS: > > http://cross-lfs.org/files/patches/1.0.0rc3/glibc-2.4-iconv_fix-1.patch
This is probably valid. I've compiled samba against glibc-2.4 but haven't yet run it. On my TODO.
> > 2) glibc-2.3.6 Linux Types Patch: relevant for compiling Xorg. Without > > the patch, some versions of Xorg (including 6.9) give compilation errors > > in agp-related file.
Simple enough to patch xorg, which is what everyone was doing before I pointed out it was a bug in Glibc.
> > 3) Gawk "invalid free" patch, incorrectly referenced as "segfault" by > > LFS. The bug is triggered by "awk '{}' no_such_file".
Show me a real life example of where this matters. I vaguely recall seeing the segfault in a config.log somewhere but I can't find it now.
Regards Greg ----
По правде, тема "патчим то, что нужно мне лично" vs "патчим все, что справедливо, даже если мне не нужно" vs "как я узнаю, что мне нужен патч?" уже обсуждалась здесь: http://www.linux.org.ru/view-message.jsp?msgid=1361924
Но там это было в другом контексте. Сейчас я хочу узнать Ваше мнение относительно только этого вопроса: абсурдна ли политика LFS, когда они применяют (правильный!) патч на каждый мелкий баг, что может сократить один день поисков? Хотели бы Вы видеть LFS с исправлениями на все случаи жизни, или без UTF-8 и с полурабочим glibc?
Чтобы предупредить возражения: более 50% упомянутых патчей взято из официальных CVS перечисленных программных продуктов и войдут в следующую версию.
