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
http://linuxfromscratch.org/~tushar/tmp/fakeroot.txt. Would
appreciate comments. I have not included the details on each
individual
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
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.
--
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
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
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
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 personally think it's more than just
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
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 continue to be
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 chapter 6,
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
Tushar Teredesai wrote:
I found too many (for my comfort) false positives and false negatives
with this method.
Snip
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
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 reinstalling glibc,
--- 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 of
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
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 development
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.
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
Randy will
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 get that
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, we
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 he
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
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
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
--
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 stuff
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
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
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.
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 destination
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 recommended
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 get that
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 get that
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?
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't
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
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
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, allowing the
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
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 install -d
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
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
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 would
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:
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
rmlscsi:
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 how to
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 installation
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
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:
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
49 matches
Mail list logo
