Pure LFS coreutils - I rest my case (temporarily :)
Bill's LFS Login
lfsbill at wlmcs.com
Fri Apr 25 03:31:29 PDT 2003
On Fri, 25 Apr 2003, Erik-Jan wrote:
> Bill's LFS Login wrote:
> > I would disagree for one reason, with a wuestion. At the time, has the
> > new su been tested?
> No, it doesn't get tested at all, it is only used in the
> fail-2eperm-test. Shadow-su (and all the other shadowprogs) doesn't get
> tested at all, though.
That doesn't concern me so much because of one thing. We have to rely on
*something* being not broken as a test basis. In this case, we must rely
on a working host and it's provided components - su in this case.
> > If not, what if it is broken and then causes the
> > fail-2eprm test to fail.
> You can look at it this way: fail-2eperm tests rm and su
I see you are bored? I already have enough fun without using an unknown
to test an unkown. By testing two unknowns simultaneously, we can have
more fun if the test fails.
> > Is this only good for the coreutils version? I suspect we will find it
> If you pass -s /bin/sh to shadow-su, it uses /bin/sh as an interactive
> login-shell. Not really what we want...
Yep. Pass /bin/bash.
> > In my final version, you'll see in the big logs that mysql didn't do
> > anything. Several were skipped and the test automativcally selected user
> > 'nobody', which is really what Ryan was shotting for anyway. So, it
> > looked pretty good to me (keeping in mind I have some degree of
> > ignorance on these things).
> Yes, it did. But adding it gives you more of that 'I know exactly what
> happens in every case'-feeling :))
With software and packages changing so rapidly, I've given up on that. I
settle for "it works" and/or "when it breaks I know enough to research
the problem and somehow get it fixed or get around it". I didn't always
take this view, but the ravages of time...
> > wonder if the coreutils install will wipe out the su from shadow, and if
> > so, will I be screwed?
> Nothing will be wiped: ch5 installs it in /stage1, ch6 installs it in
> /usr/bin (which we move to /bin) but it is the first su in the chrooted
> environment that gets installed. When we install shadow, the
> coreutils-su will be replaced by the one shadow provides. (Which is a
> good thing, I guess, because shadow-su for sure knows about shadowed
> passwords and I don't know if the coreutils-su does)
Even worse, when a new coreutils comes out and fixes many new things and
we rush to upgrade our LFS host and we forget that it installs su and we
run the standard install steps and it installs coreutils over our shadow
It's a conspiracy I tell you. A vast scheme to increase the number of
technical folks required to keep these "efficiency" tools working. The
scheme is not working well at the moment. And neither is the software.
> So it seems we've sort of got this one finished (anyone for the test
> that failed because of a missing perl expect package?)
I'm hoping that the folks who researched and produced the mini-perl
install will take this up since they already have the groundwork
lfsbill at wlmcs.com
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev