<br><br><div class="gmail_quote">On Sun, Mar 13, 2011 at 10:44 PM, DJ Lucas <span dir="ltr"><<a href="mailto:dj@linuxfromscratch.org">dj@linuxfromscratch.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


  
    
  
  <div bgcolor="#ffffff" text="#000000"><div><div></div><div class="h5">
    On 03/14/2011 12:03 AM, Nathan Coulson wrote:
    <blockquote type="cite"><br>
      <br>
      <div class="gmail_quote">On Sun, Mar 13, 2011 at 9:45 PM, DJ Lucas
        <span dir="ltr"><<a href="mailto:dj@linuxfromscratch.org" target="_blank">dj@linuxfromscratch.org</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
          <div>On 03/13/2011 11:39 PM, DJ Lucas wrote:<br>
            > Okay, so I was just
            thinking...<replaceable>&lt;Deity&gt;</replaceable><br>
            > help us! I figure we have at least 6 months,
            potentially a year until<br>
            > the next major LFS release, and now seems like a pretty
            good time to<br>
            > explore some of the ideas that have been shelved for
            previous releases,<br>
            > and even some new ones. Here is a quick list to see if
            there is any<br>
            > interest. I'll reply to my own post afterward to
            separate my own<br>
            > suggestions from the initial list.<br>
            ><br>
            > * Package Management - Always causes a good debate.<br>
            ><br>
            > * DESTDIR - Been mentioned several times and actually
            this is not too<br>
            > disruptive (I did a POC about 3 years ago).<br>
            <br>
          </div>
          For me, these two go hand in hand. Package Management,
          historically, has<br>
          always generated a fueled debate. There are many options here
          including<br>
          conditional processing of the book's sources to allow for
          various forms<br>
          of package management. I had previously suggested years ago
          that we move<br>
          the default build instructions to include a very simple
          DESTDIR style<br>
          installation, with the final installation done manually from
          the DESTDIR<br>
          target. This method lends itself well to almost all forms of
          package<br>
          management without the need of choosing a specific package
          manager. This<br>
          method also gives us the option of pre-processing the book's
          source code<br>
          for a specific package manager either by conditional logic (as
          I<br>
          understand the new docbook is capable of), or in a simpler
          form, using a<br>
          Makefile target to pre-process the book using sed or other
          standard unix<br>
          tools if the instructions are split into pre-install, build,
          install,<br>
          and post-install targets.<br>
        </blockquote>
        <div><br>
          no comment here, although I've personally preferred less
          instructions to more where possible.  (DESTDIR is not
          something I use) .  I usually throw away systems when it's
          time to upgrade though, or just install newer libs over the
          old.<br>
        </div>
        <div><br>
           </div>
      </div>
    </blockquote></div></div>
    That is part of the problem that I see. We all have our own way of
    doing things. This is actually fine, but I can see the benefit of
    standardizing some items such as package upgrades in the way of a
    wiki entry. For instance, keeping a copy of s-ls, s-rm, s-cp, and
    s-install around for glibc updates (these would be statically linked
    copies of the s- tools) which hasn't been needed for years I'm told,
    and in fact I had proven not to long ago by doing an in-place
    upgrade of GLibC while Gnome was running. :-) I'm still weary of
    doing glibc upgrades like that on a live system, perhaps it is an
    unfounded fear, but I did it on a test system just for kicks and had
    absolutely no issues. I did do a reboot immediately afterward.<div class="im"><br></div></div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im">
    <blockquote type="cite">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
          <div>
            > * LSB Compliance - For LFS we are nearly there anyway.<br>
            ><br>
            > * Dynamic boot script - No more static list of links,
            this kind of ties<br>
            > into LSB Bootscripts, but there are other options.<br>
            ><br>
          </div>
          Again, these two go hand in hand for me. In the current
          lfs-bootscripts<br>
          tarball, I've been working on and using exclusively the
          contrib/lsb-v3<br>
          boot scripts for over 3 years now. They are an extension of
          something<br>
          that Nathan Coulson and Alexander Patrakov had started on.
          These are<br>
          completely lsb-v4 compliant as well and are IMO a huge
          improvement over<br>
          the current boot scripts. I've been using Dan Nicholson's
          initd-tools<br>
          package to provide the install_initd and remove_initd
          programs. Aside<br>
          from the fact that there is no longer any need to maintain a
          list of<br>
          symlinks for startup order, they add a lot of niceties,
          including<br>
          boot-logging and conditional startup for trouble-shooting.<br>
        </blockquote>
        <div> <br>
          <br>
          ah, I miss the bootscript days.  I'll have to take a look, and
          find out what I have been missing out on<br>
        </div>
        <div> <br>
        </div>
      </div>
    </blockquote>
    <br></div>
    Yes, please! Another set of eyes and additional brain power is
    always welcome! You should still have commit privs so feel free to
    help yourself. The current 'stable' boot scripts are the remnants
    after we ripped out the i18n additions. Though they are stable, they
    still contain a lot of cruft such as boot_mesg which is largely
    unneeded. I wound up doing a complete rewrite of rc and a single
    conditional source of the configuration files in lsb-v3. IOW, at the
    cost of possibly faster conditional logic, they only get sourced by
    the script if running outside of rc in the lsb-v3 directory. I
    honestly don't remember what the 'stty sane' issue was caused by,
    but I have never been able to reproduce it since and saw no reason
    to source the files in every single sub-shell. BTW, Dan's
    initd-tools has moved. He is currently hosting them in his home
    directory on <a href="http://freedesktop.org" target="_blank">freedesktop.org</a>.</div></blockquote><div><br> <a href="http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg00492.html">http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg00492.html</a><br>
<br>something to do w/ delete or backspace turning into ^H, if I recall,    I think it also prevent someone from pressing enter when something paused the bootup.  Whatever it was, it was 5 years ago...  if not longer.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><div class="im"><br>
    <br>
    <blockquote type="cite">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
          <div>
            > * Multi-lib - Shunned previously, but there are many
            projects that<br>
            > expect this environment.<br>
            <br>
          </div>
          I just kinda threw that in there. A couple of projects that I
          use beyond<br>
          BLFS expect that environment now for 64bit builds,
          specifically AOSP,<br>
          Wine, and VirtualBox, all of which forcefully exclude the
          official LFS<br>
          as my daily driver now. I've been using the work of the CLFS
          devs for my<br>
          own daily driver with some heavy modifications to match LFS
          proper as<br>
          much as possible.<br>
        </blockquote>
        <div><br>
          When I designed my own multilib system,  I had a few goals<br>
          - 32bit was not a essential part of my system.  Only reason I
          have it is for wine, basically...<br>
          - I wanted /lib 64bit.   Therefore, I used /lib/32 for 32bit
          libs (although /lib32 would probably be a better book
          choice).  [always bugged me that /lib is normally the 32bit
          directory, especially since it is the default installation
          choice]<br>
        </div>
        <div>- If possible, I would have liked to see multilib avaliable
          "after" building lfs, but this is probably not feasable.<br>
          - I only install 32bit versions of glibc, zlib, ncurses,
          utillinux as they're the only ones I actually needed for my
          32bit uses.  May be worth reviewing who would be using 32bit,
          and what applications it would be supporting.  Multilib in the
          book would look nicer, if only glibc/gcc/binutils had multilib
          tweaks.  (Enough to compile 32bit software)<br>
           
          <br>
        </div>
      </div>
    </blockquote></div>
    Yes, unfortunately, the tool chain packages are not enough to do a
    real multi-lib system. For my own purposes, I need a working 32bit
    tool chain, 32bit X Libraries and server, and 32bit libs up through
    java. Most of this is for Android development. For LFS's purposes,
    the tool chain is enough however and pretty much what CLFS covers
    (this includes PPL, Cloog-PPL, GMP, MPFR, MPC. ZLib, Binutils,
    GLibC, and GCC). PERL is a real kicker that brings in more 32bit
    libs than the tool chain requirements. I haven't tried to build a
    multi-lib without it yet to see if it is needed by my own tools, but
    I suspect that a lot uses it. If a user is dabbling in multi-lib,
    then they should be able to figure out exactly what they need by
    using the existing instructions. This paired with DESTDIR style
    installations provides some protection to the user as well. BTW
    Nathan, I did use your page to figure out what exactly needed to be
    changed in the GCC drivers as opposed to sorting through the CLFS
    patch. I made changes, but that write-up was quite helpful. Thanks.</div></blockquote><div class="im"><br>I should finish that writeup someday...  There was some change we made to the gcc page that I couldn't quite make work w/ multilib, so I just used the old way.<br>
<br>
    <blockquote type="cite">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
          <div>
            > * EGlibC - Seems like Debian and friends are moving to
            EGlibc, gives us<br>
            > a couple of niceties but nothing major, not sure what
            other distros are<br>
            > doing, but I've seen a lot of mentions of it recently.
            The work is<br>
            > already done by the way, our fellow devs at CLFS
            already have it covered<br>
            > for us.<br>
            <br>
          </div>
          Same thing, I've seen lots of mentions of it so I'm throwing
          out the<br>
          feelers. CLFS has already done this and I've used both. I have
          no real<br>
          opinion either way yet. I did not have anything more than
          minor issues<br>
          making GLibC proper conform to my expectations (/lib ->
          lib64/, /usr/lib<br>
          -> /usr/lib64, /lib32, and /usr/lib32).<br>
          <div><br>
            > * Modular *.d/ directories - I'm pretty sure this is
            already covered in<br>
            > another thread, but it should be done by default where
            possible.<br>
            ><br>
            <br>
          </div>
          As mentioned elsewhere recently, this gives a lot of options,
          and in<br>
          fact are required by a few packages in BLFS. I see absolutely
          no reason<br>
          to omit this as the default using the instructions currently
          in BLFS as<br>
          a guideline for strict conformance.<br>
        </blockquote>
        <div><br>
          using .d folders has made scripted builds much nicer, and It
          seems tidier to me.<br>
        </div>
      </div>
    </blockquote>
    <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000">
    Yes, the end product of modular parts simply looks much cleaner.<br><font color="#888888">
    <br>
    -- DJ Lucas<br>
    <br>
  </font></div><div><div></div><div class="h5">
<br>-- 
<br>This message has been scanned for viruses and
<br>dangerous content, and is believed to be clean.


</div></div><br>--<br>
<a href="http://linuxfromscratch.org/mailman/listinfo/lfs-dev" target="_blank">http://linuxfromscratch.org/mailman/listinfo/lfs-dev</a><br>
FAQ: <a href="http://www.linuxfromscratch.org/faq/" target="_blank">http://www.linuxfromscratch.org/faq/</a><br>
Unsubscribe: See the above information page<br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Nathan Coulson (conathan)<br>------<br>Location: British Columbia, Canada<br>Timezone: PST (-8)<br>Webpage: <a href="http://www.nathancoulson.com" target="_blank">http://www.nathancoulson.com</a><br>