Dan Nicholson wrote:
> In the end, I'm sorry I've argued as much as I have because this is a
> good technique, and I don't care enough whether it's in the book or
> not.
Fist of all, you are not arguing, you are discussing and advocating. To
me arguing implies discord. I havn't seen that. Seco
Jeremy Byron wrote:
still have the sed in the book for unxlngi6.mk. There are a few files
that have this problem and unxlngi6.mk is no longer one of them so the
Sorry, my bad.. unxlngi6.mk still has the problem but so does a few
other files. No point fixing one and not the others and, unles
I tried building OOo2 again using the instructions in the book seeing as
people are saying they have successful builds, but I don't see how they
could without a lot of monkeying on their own.
The bsh download is "..b4-src.tar.bz2" but the copy and decompression
command references "..b4.tar.bz2
Jeremy Huntwork wrote:
Chris Staub wrote:
Of course the question is "what is the goal of LFS?". If it is just to
teach how to build a minimal, working system, then this suggested
addition isn't necessary - why does LFS need to worry about how users
use the system once it's built? There are pl
I came to LFS because I was interested in learning the "process" of
building a stable linux system. Not just to follow a recipe for
building one. One of the things I found to be lacking was more of an
explanation of the process of evaluating new packages and how they
change your system. This may or
On 11/29/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote:
> The only difference I see as compared to what is in LFS is the
> addition of $PM_DEST. If the envar is not set. I don't think it
> creates any chances for typos. In the worst case if the user forgets
> to set $PM_DEST, it would install stuf
On 11/29/05, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> However, if the book's main intent IS to be a learning experience and
> provide a high level of success for newbies, I think adding that
> fakeroot approach adds too much complexity and chances for errors. To
> see an example of what the fak
Jeremy Huntwork([EMAIL PROTECTED])@Tue, Nov 29, 2005 at 12:32:59PM -0500:
>
Snip
>
> I think we really should look at including it sometime in the future,
> whether it starts with a hint or a separate branch or whatever.
>
Ok lets give an end to these eternals debates (although i have to
admi
On Tue, 29 Nov 2005, Randy McMurchy wrote:
Though I've never seen a situation where I 'ran into a problem during
make install', I suppose it could happen.
Just wait till you move to a multilib machine ;)
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratc
Jeremy Huntwork wrote:
Chris Staub wrote:
Something like DESTDIR could be added, but stating that it's optional.
I'm sorry, I thought it was understood that it would be optional. Tushar
suggested a variable that, if it was unset, would skip the functionality.
I know it has been suggested a
Dan Nicholson wrote:
location like it does with /tools). Greg gets away with this by
putting right at the beginning that DIY is not for newbies and you
should go to LFS if you are.
Which isn't right. LFS is about education, but not educating 'newbies'.
Note that I interepret newbies to be lin
Chris Staub wrote:
A large part of the way the book is written in the first place doesn't
have anything to do with technical issues - part of the reason for it is
to teach people how to build a Linux system and how it works. I'm
undecided myself whether adding this stuff to the book helps in t
Randy McMurchy wrote:
However, I thought our goal was to provide instructions to build a
safe, secure, accurate Linux system. Why should readers not trust the
book and do extra steps to ensure what *the Editors* say is the
steps to accomplish this.
Except that as you pointed out earlier, a sysa
On 11/29/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
>
> > I agree with Tushar that this is a good reason for fakeroot. I have
> > had the exact situation he's describing before. When your building a
> > package and following a known good recipe (a la BLFS), this is
> >
Jeremy Huntwork wrote:
I don't know. If we don't insert it in the book, what's the reason?
Because we're trying to keep LFS simple? Pfft. LFS by nature isn't
simple. I doubt Gerard started the project because he wanted to keep his
personal desktop 'simple'. Uncluttered and clean and minimal,
Jeremy Huntwork wrote these words on 11/29/05 11:32 CST:
> Quite frankly, from the comments I've been reading, most of those who
> are opposed to putting this type of info in the book aren't giving
> technical reasons.
That's not true. The reasons stated have been accurate. They may not
be "tec
Dan Nicholson wrote:
I agree with Tushar that this is a good reason for fakeroot. I have
had the exact situation he's describing before. When your building a
package and following a known good recipe (a la BLFS), this is
unlikely, but it happens. It's not pleasant to deal with. Either
way, I
On 11/29/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Tushar Teredesai wrote these words on 11/29/05 10:34 CST:
>
> > Just thought of another advantage of the fake root method. If the
> > package installation fails for some reason, we don't have an half
> > installed package in the final destina
DJ Lucas wrote:
Thanks Andy. I did exactly the same last night, and did test...I just
hadn't commited it yet. Just change the extern to static in the newly
created hetio.h and all is well. I will commit your patch and update
the book a little later tonight.
Don't tell them that, make it so
Tushar Teredesai wrote these words on 11/29/05 10:34 CST:
> Just thought of another advantage of the fake root method. If the
> package installation fails for some reason, we don't have an half
> installed package in the final destination. For example, when the user
> is building gcc in BLFS and h
On 11/27/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote:
> There are multiple advantages that this offers compared to the current
> way of installing directly into the final destination:
Just thought of another advantage of the fake root method. If the
package installation fails for some reason, w
On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Tushar Teredesai wrote these words on 11/28/05 09:59 CST:
> > On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> >>If it isn't a trust thing, and you want to figure out what all is
> >>being installed, then there are many, many ways to
On 11/29/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Tushar Teredesai wrote:
> >
> > Yep, and DESTDIR being the easiest and recommended (in the READMEs) way.
>
> I can't possibly agree with that. `touch timestamp && [book
> instructions] && find / -newer timestamp` works fine for me, though
>
On 11/28/05, DJ Lucas <[EMAIL PROTECTED]> wrote:
> Also, just to throw a bone in the mix, :-) there is no need to use
> DESTDIR nowadays for a glibc upgrade as the libs are installed to a temp
> file and then pivoted into the new location safely. In fact, glibc does
> not recomend DESTDIR at all.
Matthew Burgess wrote:
> `touch timestamp && [book
> instructions] && find / -newer timestamp` works fine for me
The advantage if DESTDIR is that you can check what will be installed
*before* it is actually installed. I think that, for the most part,
this may be more important for BLFS developme
Matthew Burgess wrote:
Tushar Teredesai wrote:
On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
If it isn't a trust thing, and you want to figure out what all is
being installed, then there are many, many ways to get that data.
Yep, and DESTDIR being the easiest and recommended (in
--- Bryan Kadzban <[EMAIL PROTECTED]> wrote:
> > Which means almost all packages used by LFS and
> BLFS should be able to
> > use it.
>
> All except the ones that don't believe in automake
> for whatever reason.
>
By example the first package in BLFS book, autofs,
which use INSTALLROOT instead
27 matches
Mail list logo
