Re: More control...hint integration discussion

On 12/10/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > For folks who would like to test out the fakeroot approach, I have put > up a draft version of a hint at > . Would > appreciate comments. I have not included the details on each > indivi

Re: More control...hint integration discussion

On 11/29/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > 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. Since there have been no indications in either direction from the project leads, I am assuming that usin

Re: More control...hint integration discussion

On 11/30/05, DJ Lucas <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > > It will work for Ch 6 only as long as we are installing it inside > > chroot. But I meant more in terms of using it for package management. > > The above technique gave me the following problems: > > 1. When reinstal

Re: More control...hint integration discussion

Tushar Teredesai wrote: I found too many (for my comfort) false positives and false negatives with this method. It will work for Ch 6 only as long as we are installing it inside chroot. But I meant more in terms of using it for package management. The above technique gave me the followi

Re: Experimental ELFS (Was: Re: More control...hint integration discussion)

Matt Darcy([EMAIL PROTECTED])@Wed, Nov 30, 2005 at 09:44:48AM +: Sometimes i am trying to > > > so you mean the lfs-development book then.. > In fact i was talking for an entirely different concept with different priorities but with just one target. To improve the LFS projects. However

Re: More control...hint integration discussion

On 11/30/05, Matthew Burgess <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > I found too many (for my comfort) false positives and false negatives > > with this method. > > Presumably because you were doing other things with the computer at the > same time? When run inside chroot in cha

Re: More control...hint integration discussion

Matt Darcy wrote: > >> >> Ah, yes. The Ultimate Question of Life, the Universe and Everything >> LFS. I personally think it's more than just building a minimal working >> system, and I think there are others that will agree with me there. >> That should be shown by the fact that there are and cont

Re: More control...hint integration discussion

Kev Buckley wrote: Ah, yes. The Ultimate Question of Life, the Universe and Everything LFS. I personally think it's more than just building a minimal working system, and I think there are others that will agree with me there. That should be shown by the fact that there are and continue to be

AW: More control...hint integration discussion

EMAIL PROTECTED] Auftrag von Kev Buckley Gesendet: Mittwoch, 30. November 2005 11:57 An: lfs-dev@linuxfromscratch.org Betreff: Re: More control...hint integration discussion > > > > > > Ah, yes. The Ultimate Question of Life, the Universe and Everything LFS. > > I persona

Re: More control...hint integration discussion

> > > > > > Ah, yes. The Ultimate Question of Life, the Universe and Everything LFS. > > I personally think it's more than just building a minimal working > > system, and I think there are others that will agree with me there. That > > should be shown by the fact that there are and continue t

Re: More control...hint integration discussion

Ah, yes. The Ultimate Question of Life, the Universe and Everything LFS. I personally think it's more than just building a minimal working system, and I think there are others that will agree with me there. That should be shown by the fact that there are and continue to be such packages as

Re: Experimental ELFS (Was: Re: More control...hint integration discussion)

Ag Hatzim wrote: 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

Re: More control...hint integration discussion

Chris Staub wrote: It would really be nice if the book had more documentation on the book itself - how it got to be the way it is (besides having to search the mailing lists). Ah, yes, "The Design and Evolution of LFS" (with apologies to Bjarne Stroustrup). :-) Matt. -- http://linuxfromscra

Re: More control...hint integration discussion

Tushar Teredesai wrote: I found too many (for my comfort) false positives and false negatives with this method. Presumably because you were doing other things with the computer at the same time? When run inside chroot in chapter 6, unless you're directly fiddling with files (or installing m

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Experimental ELFS (Was: Re: More control...hint integration discussion)

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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 > >

Re: More control...hint integration discussion

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,

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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 >

Re: More control...hint integration discussion

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.

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

--- 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

Re: More control...hint integration discussion

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 the READMEs) way. I can't

Re: More control...hint integration discussion

Tushar Teredesai wrote: On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: Or, to look at it another way, folks that *do* want to use the DESTDIR approach can simply add it to the instructions. :-) I have been using that approach and it is not as easy as that. Sometimes, we need to make

Re: More control...hint integration discussion

On 11/28/05, Archaic <[EMAIL PROTECTED]> wrote: > On Mon, Nov 28, 2005 at 09:59:24AM -0600, Tushar Teredesai wrote: > > > > I have been using that approach and it is not as easy as that. > > Sometimes, we need to make sure that the destination dirs exist before > > installing (i.e. have some instal

Re: More control...hint integration discussion

On Mon, Nov 28, 2005 at 09:59:24AM -0600, Tushar Teredesai wrote: > > I have been using that approach and it is not as easy as that. > Sometimes, we need to make sure that the destination dirs exist before > installing (i.e. have some install -d before the make DESTDIR=.. > install. Then I would

Re: More control...hint integration discussion

Alexander Lang wrote: > Tushar Teredesai wrote: > >>What do other LFSers think? > > > I have another idea (maybe it exists already, maybe not): > I recently discovered uninonfs > (http://www.fsl.cs.sunysb.edu/project-unionfs.html) and it seems to me, > that it could be used for our purpose, allo

Re: More control...hint integration discussion

Alexander Lang wrote: I have another idea (maybe it exists already, maybe not): I recently discovered uninonfs (http://www.fsl.cs.sunysb.edu/project-unionfs.html) and it seems to me, that it could be used for our purpose, allowing the instructions to remain as they are now: Despite it's popular

Re: More control...hint integration discussion

Tushar Teredesai wrote: > > What do other LFSers think? I have another idea (maybe it exists already, maybe not): I recently discovered uninonfs (http://www.fsl.cs.sunysb.edu/project-unionfs.html) and it seems to me, that it could be used for our purpose, allowing the instructions to remain as th

Re: More control...hint integration discussion

On Mon, Nov 28, 2005 at 09:48:41AM -0700, Dennis J Perkins wrote: > Isn't DESTDIR something that the autoconf package automatically > provides? Well, automake (not autoconf), but yes. > Which means almost all packages used by LFS and BLFS should be able to > use it. All except the ones that don'

Re: More control...hint integration discussion

> > BTW, this is the first I have heard of maintainers recommending *not* > to use DESTDIR based approach since that is how packages are installed > by most of the distros (including the source based ones like Gentoo). > Isn't DESTDIR something that the autoconf package automatically provides?

Re: More control...hint integration discussion

Tushar Teredesai wrote: BTW, this is the first I have heard of maintainers recommending *not* to use DESTDIR based approach since that is how packages are installed by most of the distros (including the source based ones like Gentoo). I think employing DESTDIR would be an educating and worthwh

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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

Re: More control...hint integration discussion

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 get that data. > > Yep, and DESTDIR being the easiest and reco

Re: More control...hint integration discussion

On 11/28/05, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > Actually, you have that a bit backwards. TT_PFX is the variable Greg > uses for /tools or whatever. You're thinking of PM_DEST, the variable > where the package manager root is set. So that's > > make DESTDIR=$PM_DEST install Thanks, I c

Re: More control...hint integration discussion

On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > Or, to look at it another way, folks that *do* want to use the DESTDIR > approach can simply add it to the instructions. :-) I have been using that approach and it is not as easy as that. Sometimes, we need to make sure that the destinatio

Re: More control...hint integration discussion

On 11/27/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > On 11/27/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > > Disadvantages: > > * It makes the instructions slightly more complex. > > * Causes problems for folks who don't want a package manager. > > Actually, we can do what Greg has done.

Re: More control...hint integration discussion

Tushar Teredesai wrote these words on 11/28/05 00:13 CST: > Actually, we can do what Greg has done. He uses TT_PFX as the DESTDIR > and instead of make install, he does make DESTDIR=$TT_PFX install. > Someone who does not want to use the DESTDIR approach can just unset > TT_PFX and the installatio

Re: More control...hint integration discussion

On 11/27/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > Disadvantages: > * It makes the instructions slightly more complex. > * Causes problems for folks who don't want a package manager. Actually, we can do what Greg has done. He uses TT_PFX as the DESTDIR and instead of make install, he does

Re: More control...hint integration discussion

On 11/27/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote these words on 11/27/05 23:06 CST: > > > What do other LFSers think? > > -1 for all the same reasons that I and many others have already > stated. Additionally, I don't believe that the goal of LFS is to > teach folks h

Re: More control...hint integration discussion

Tushar Teredesai wrote these words on 11/27/05 23:06 CST: > What do other LFSers think? -1 for all the same reasons that I and many others have already stated. Additionally, I don't believe that the goal of LFS is to teach folks how to "create a distribution", as you mentioned. -- Randy rmlscs

Re: More control...hint integration discussion

Tushar Teredesai wrote: What do other LFSers think? It sounds more like what I originally was looking but didn't fully know how to achieve outside of the package users hint. Thanks Tushar. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/fa

Re: More control...hint integration discussion

On 11/25/05, Gerard Beekmans <[EMAIL PROTECTED]> wrote: > Jeremy's idea of using portions of that hint has merit, but I agree the > hint as-is isn't suitable for the book. I was going to post something along similar lines. I have it sitting in my Drafts folder, so will just cut-n-paste it. I woul

Re: More control...hint integration discussion

Gerard Beekmans wrote: There exist programs like checkinstall, install-log, and myriad others by now that are able to get us that kind of information. These programs and scripts act as wrappers around "make install" processes usually and track what is being done (and output of these tools can

Re: More control...hint integration discussion

Gerard Beekmans wrote: Jeremy's idea of using portions of that hint has merit, but I agree the hint as-is isn't suitable for the book. Thank you Gerard. I think you picked up the gist of what I was trying to achieve. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://w

More control...hint integration discussion

Jeremy's idea of using portions of that hint has merit, but I agree the hint as-is isn't suitable for the book. However, there are other ways to obtain the same information. I think most people will agree the key element here is learning exactly which files get installed, if they are setuid ro