Here are my responses. I use a homegrown pkg manager. It used to be
based on the pkg-user + fakeroot approach, but the latest one I am
using has the pkg-user stuff removed since I found it was adding a lot
of complexity without much benefit. My current PM uses a fakeroot
approach by building and fa
On Mon, Mar 3, 2008 at 2:56 PM, Greg Schafer <[EMAIL PROTECTED]> wrote:
> Sukucorp Sukucorp wrote:
>
> Arghh! Please stop mis-using the term "fakeroot". The real Fakeroot is a
> Debian package designed to simulate a superuser environment. What you are
> refer
On Mon, Mar 24, 2008 at 5:55 AM, Alan Lord <[EMAIL PROTECTED]> wrote:
> This even applies to Ubuntu 64bit which I have tried. I removed it
> within a few hours when I couldn't load Acrobat reader, various media
> codecs and several other apps...
>
I have been using Ubuntu Gutsy x86_64 since its
On Mon, Mar 31, 2008 at 9:53 AM, Randy McMurchy
<[EMAIL PROTECTED]> wrote:
>
> I've almost completed an LFS Development build using DESTDIR (or whatever
> else if the package doesn't support DESTDIR) style installation. Though
> I might hit some bumps in the last few remaining packages, I'm writ
On undefined, Dave Wheeler <[EMAIL PROTECTED]> wrote:
> I agree w/ pretty much everything said below and would also like to
> see a DESTDIR-branch. I'd add the uninstall commands should also be
> broken out into pre- and post- stages. An example would be calling
> pwunconv and grpunconv if you
On undefined, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> But what is being described here is much more than just a DESTDIR
> installation method. To me, this sounds like pure PM, and probably
> more than LFS should take on.
>
It is not more than the DESTDIR method. If packages are installed
On Mon, Mar 31, 2008 at 5:12 PM, Bryan Kadzban
<[EMAIL PROTECTED]> wrote:
> But any kind of DESTDIR type
> setup would require it, if the package's "make install" is run as a
> non-root user.
fakeroot is not an absolute requirement for install-root style PM. I
use the following wrappers to avoi
On Fri, Apr 11, 2008 at 2:48 PM, <[EMAIL PROTECTED]> wrote:
> + [bdubbs] - Updated host requirments to check for
> + symbolic links from sh, awk, and yacc.
Was there a bug report for this or did anyone run into any problems?
I don't know about bison/yacc, but I did not have a
On Fri, Apr 11, 2008 at 3:23 PM, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>
> I was responding to some earlier comments about sh->dash causing problmes. I
> added the part about yacc and awk because I know thy are sometimes used, but
> I
> don't know for sure if they are essential for LFS. It i
On Fri, Apr 11, 2008 at 4:30 PM, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>
> yacc (bison) - Definitely needed since we patch the bash parse.y file
> in Ch. 5 and yacc will need to be rerun. Could add bison to Ch. 5
> before bash, but IMO it's easier for the host to just install bison.
I don't
On Fri, Apr 11, 2008 at 6:01 PM, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> > Randy echoed my thoughts in a much better manner. We should not check
> > for something if the result of the check does not make any difference
> > in the build.
>
> Agreed, and I don't think we're doing that right
On Sat, Apr 12, 2008 at 5:28 PM, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>
> I'm not sure why. The changes I added only say to change some (three)
> symbolic
> links or add them if they don't already exist. These changes to links can't
> really hurt and it establishes a better base configurat
On Sat, Apr 12, 2008 at 7:34 PM, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>
>
> We had a discussion about this in:
>
> http://wiki.linuxfromscratch.org/lfs/ticket/1962
>
> and although that got resolved, I was trying to head off potential future
> problems.
That was fixed upstream. Most of the u
13 matches
Mail list logo
