I'd like to give my opinion and 2 cents worth to this topic, even if I'm not a
regular
member or contributor. I've been reading the forums more regularly recently.
I came across LFS 3 - 4 years ago, when I got upset with all other
distributions that I
had tried. Upset mainly because of their PM
Alexander E. Patrakov wrote these words on 08/16/07 00:51 CST:
> Slackware packages never ship configuration files that are supposed to
> be modified by end users. Instead, such configuration files are shipped
> with the .new extension, and a post-installation script handles this.
This to me i
Bruce Dubbs wrote:
> There is a problem that I see from the above description. It may or may
> not be an actual problem.
>
> What about a config file that *is* installed in a package and may be
> modified by a user? Examples might be /etc/php.ini or
> /etc/apache/httpd.conf. I wouldn't want thes
Greg Schafer wrote:
> This is all covered in the DIY Refbuild doc. Pls read it. I need to keep
> "make bootstrap" because I support multiple versions of GCC with the one
> set of build commands.
Yep, thanks. I saw that you used --disable-bootstrap the last time I
visited, but missed the note. I s
Jeremy Huntwork wrote:
> Looking at gcc-4.2.1's configure, I see that --enable-bootstrap seems to
> be the default if we are building native.
Yes, it changed in 4.2.
> but perhaps you know the answer already. Does this mean that GCC by
> default is doing what it used to do when calling 'make b
Greg Schafer wrote:
> I'll chew on it for a while and maybe try some tests.
Greg,
Looking at gcc-4.2.1's configure, I see that --enable-bootstrap seems to
be the default if we are building native. I'm trying to read what I can,
but perhaps you know the answer already. Does this mean that GCC by
Greg Schafer wrote:
> Hmmm, thinking about this some more, there might actually be another
> option and that's the one already raised by Alex ie: don't bootstrap GCC
> pass1 (possibly move the bootstrap to pass2 as suggested by Jeremy). As it
> currently stands, the new tools start being used in co
Jeremy Huntwork wrote:
> And for that reason I think I would be against adding a specific PM to
> LFS/BLFS. However, dropping in a DESTDIR framework would allow for
> *most* package managers to be used without adding any further specifics.
>
> At this point, whether or not LFS or BLFS decide to us
Greg Schafer wrote:
> The facts are, our current native build method relies on the ability to
> link against the host libc with the target ld. There is nothing inherently
> wrong with this approach because it should always work in typical LFS
> build scenarios (barring bugs of course). Yes, it wou
Craig Jackson wrote:
> I would love to help. I do have a couple of questions so we can
> hopefully be more effective at this.
Hi Craig. Thanks for the reply!
> 1. What are some examples of common issues that users have reported
> that you feel would benefit from a bit of automated testing? Ther
> * Developers to experiment with and present new concepts for the CDs
> * Maintainers to help build the CDs, correct flaws in the build
> scripts, update (and test) existing software included on the CDs
> * Testers to download the isos, run as much of the software on as wide
> a range of mac
On Tuesday 24 July 2007 07:56, Dan Nicholson wrote:
...
> and
> noticed some && in chained commands. It seems that usual way in LFS is
> not to do this.
Curious; is this just a style preference?
I notice in Chapter 5 Adjusting the Toolchain:
-
GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
taipan67 wrote:
> Bryan Kadzban wrote:
>> DESTDIR=$dest on all the packages, for instance, shouldn't hurt if
>> $dest is empty.
>
> Obviously $dest must be "chgrp install && chmod 1775" in such a case,
The case where $dest is empty? :-P
> but
taipan67 wrote:
> Bryan Kadzban wrote:
>
>> I'm going to tentatively vote -1 for package management in LFS -- that
>> is, unless it doesn't break my current package management setup
>> (pkg-user hint FTW!). If the changes don't break the pkg-user hint,
>> then I'd say +1; it's worth a shot at l
On Wednesday 15 August 2007 3:20:38 pm Jeremy Huntwork wrote:
> I hate to say it, but I don't recall your system. Do you have a link of
> some sort?
I did post a couple of replies with links in them but they may have been
considered spam and they don't seem to have gotten through. You can look
t
Meant to CC this to lfs-dev for the sake of visibility.
- Forwarded message from Jeremy Huntwork <[EMAIL PROTECTED]> -
To: [EMAIL PROTECTED]
From: Jeremy Huntwork <[EMAIL PROTECTED]>
Date: Wed, 15 Aug 2007 12:05:45 -0600
User-Agent: Mutt/1.5.11
Subject: New LiveCD master server
Hello all
Jeremy Huntwork wrote:
> What I do like about it is that it adds a useful feature (for some),
> offers flexibility, and offers areas for greater education. It could be
> argued that by inspecting the contents of DESTDIR after they run the
> make install command there is additional opportunity for b
Jeremy Huntwork wrote these words on 08/15/07 12:53 CST:
> What I do like about it is that it adds a useful feature (for some),
> offers flexibility, and offers areas for greater education. It could be
> argued that by inspecting the contents of DESTDIR after they run the
> make install command th
Bryan Kadzban wrote:
> I'm going to tentatively vote -1 for package management in LFS -- that
> is, unless it doesn't break my current package management setup
> (pkg-user hint FTW!). If the changes don't break the pkg-user hint,
> then I'd say +1; it's worth a shot at least. DESTDIR=$dest on all
On Wednesday 15 August 2007 8:53:23 pm Jeremy Huntwork wrote:
> offers areas for greater education. It could be
> argued that by inspecting the contents of DESTDIR after they run the
> make install command there is additional opportunity for builders to get
> familiar with what exactly is going to
Jeremy Huntwork wrote:
> On Wed, Aug 15, 2007 at 10:17:51AM -0700, lists wrote:
>> If the editors pick a pm, then they are removing the "choice" part of that.
>
> And for that reason I think I would be against adding a specific PM to
> LFS/BLFS. However, dropping in a DESTDIR framework would allow
On Wed, Aug 15, 2007 at 12:38:26PM -0500, Randy McMurchy wrote:
> I realize I'm making a case for using it saying the above, however,
> I don't feel we need to push it onto users. Merely suggesting it,
> *and letting the reader make the choice to do it or not*, should
> be more than ample. The read
Randy McMurchy wrote:
> david567 wrote these words on 08/15/07 11:45 CST:
>
>> Randy McMurchy wrote:
>>
>
>
>> Indeed, the book would need to be the implementation.
>>
>
> My point exactly. You are suggesting a total implentation, where
> all we really need to do is explain *how* to
Jeremy Huntwork wrote these words on 08/15/07 12:06 CST:
> By the same token, once you get past the initial work of adding the PM
> framework to BLFS, it might make developing and testing BLFS a whole lot
> easier, simply because of the nature of package managment. But, you're
> more qualified to
On Wed, Aug 15, 2007 at 10:17:51AM -0700, lists wrote:
> If the editors pick a pm, then they are removing the "choice" part of that.
And for that reason I think I would be against adding a specific PM to
LFS/BLFS. However, dropping in a DESTDIR framework would allow for
*most* package managers to
On Wed, Aug 15, 2007 at 07:07:40AM -0600, Jeremy Huntwork wrote:
> On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote:
> > I'll go on record as -1.
>
> I'm not going to push to get this into LFS. If the vast majority of
> those with a voice here are for PM in LFS, great. If not, great.
Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 08/15/07 11:42 CST:
>
~snip~
>
> I can't see it happening in BLFS for the simple reason that it would
> be a monumental task (automating the proper inserts could perhaps be
> done, but we wouldn't do that until *every* package has been
On Wed, Aug 15, 2007 at 12:05:09PM -0500, Bruce Dubbs wrote:
> Having said that, I am not opposed to a PM hint (which already exists)
> or even a entirely new project "PM for LFS". A relatively small book
> that explains package management and one (or more) methods may be a nice
> compliment to th
On Wed, Aug 15, 2007 at 11:59:34AM -0500, Randy McMurchy wrote:
> I can't see it happening in BLFS for the simple reason that it would
> be a monumental task (automating the proper inserts could perhaps be
> done, but we wouldn't do that until *every* package has been tested,
> which again would be
Randy McMurchy wrote:
> I can't see it happening in BLFS for the simple reason that it would
> be a monumental task (automating the proper inserts could perhaps be
> done, but we wouldn't do that until *every* package has been tested,
> which again would be monumental).
>
>
The 'BLFS' task is al
david567 wrote these words on 08/15/07 11:45 CST:
> Randy McMurchy wrote:
> Indeed, the book would need to be the implementation.
My point exactly. You are suggesting a total implentation, where
all we really need to do is explain *how* to implement if the
reader wants. Not intrusive that way. No
Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 08/15/07 07:20 CST:
>
>> I would love to see some sort of proper support for PM go into LFS, but
>> that all depends on the community...
>
> I'll go on record as -1.
>
> I feel we should mention it, provide links to the various altern
On Wed, 2007-08-15 at 10:43 -0500, Kevin Day wrote:
> Okay, so I finally found out how to make udev's > 094 boot under a
> uClibc system.
>
> During the boot process prior to loading/starting udev, I have the
> following command happening:
> echo /sbin/udevtrigger > /proc/sys/kernel/hotplug
> This
Jeremy Huntwork wrote these words on 08/15/07 11:42 CST:
> Taking this a step further, the commands for most packages could be
> probably be unaffected entirely if you set DESTDIR to be an environment
> variable, as in config.site. Note that I haven't tested this.
DESTDIR would then have to be cl
Alexander E. Patrakov wrote:
> Mike Lynch wrote:
>> One of the nice things about the Solaris package manager is that *every*
>> file installed is registered in a database (just an CSV file so no DB
>> software
>> like SQL needed) so it's easy to find out what has been installed. Package
>> remova
Randy McMurchy wrote:
> david567 wrote these words on 08/15/07 10:56 CST:
>
>> Randy McMurchy wrote:
>>
>>> I feel we should mention it, provide links to the various alternatives,
>>> and drive on. We are not a distribution. We are a book that shows how
>>> to compile Linux from scratch. Le
On Wed, Aug 15, 2007 at 10:37:44AM -0600, Jeremy Huntwork wrote:
> Not in the least. If DESTDIR is set to an empty variable, the effect of
> the command is the same as usual.
>
> ./configure --prefix=/usr && make && make install
> is the same as
> ./configure --prefix=/usr && make && make DESTDIR=
Jeremy Huntwork wrote these words on 08/15/07 11:37 CST:
> Not in the least. If DESTDIR is set to an empty variable, the effect of
> the command is the same as usual.
Agreed. I forgot about that.
--
Randy
rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stab
On Wed, Aug 15, 2007 at 11:34:34AM -0500, Randy McMurchy wrote:
> If something were to be implemented, even a DESTDIR foundation without
> full PM capability, would ruin cut-and-paste capability for the scores
> of readers that don't want the bloat a PM brings into the picture.
Not in the least. I
david567 wrote these words on 08/15/07 10:56 CST:
> Randy McMurchy wrote:
>> I feel we should mention it, provide links to the various alternatives,
>> and drive on. We are not a distribution. We are a book that shows how
>> to compile Linux from scratch. Let's don't forget that.
>>
> No, lets n
On Wednesday 15 August 2007 3:20:38 pm Jeremy Huntwork wrote:
> Shane Shields wrote:
> > On 15 Aug 2007 Wed 11:25 am, Alan Lord wrote:
> >> Jeremy - that sounds like a cracking idea but I strongly believe that it
> >> should go much further than the LiveCD...
> >
> > Strongly agree
>
> I would love
Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 08/15/07 07:20 CST:
>
>
>> I would love to see some sort of proper support for PM go into LFS, but
>> that all depends on the community...
>>
>
> I'll go on record as -1.
>
> I feel we should mention it, provide links to the vari
On Wednesday 15 August 2007 3:20:38 pm Jeremy Huntwork wrote:
> I would love to see some sort of proper support for PM go into LFS, but
> that all depends on the community...
That is what makes LFS so good. I plug it on my blog whenever I get the
chance.
http://blogs.ittoolbox.com/linux/locutus
lists wrote:
> Jeremy Huntwork wrote:
>
>> On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote:
>>
>>> I'll go on record as -1.
>>>
>> I'm not going to push to get this into LFS. If the vast majority of
>> those with a voice here are for PM in LFS, great. If not, great. :)
Okay, so I finally found out how to make udev's > 094 boot under a
uClibc system.
During the boot process prior to loading/starting udev, I have the
following command happening:
echo /sbin/udevtrigger > /proc/sys/kernel/hotplug
This works in udev094, for whatever reason it now causes udev to lock
M.Canales.es wrote:
> What changes would be needed to let *LFS books be PM-aware? Without forcing
> the use of an specific PM implementation, of course.
>
DESTDIR (see how DIY handles it) and workarounds for parameters detected
incorrectly by ./configure scripts when running as non-root.
--
El Miércoles, 15 de Agosto de 2007 15:07, Jeremy Huntwork escribió:
> I'm not going to push to get this into LFS. If the vast majority of
> those with a voice here are for PM in LFS, great. If not, great. :)
The question are:
What changes would be needed to let *LFS books be PM-aware? Without fo
TheOldFellow wrote:
> On Wed, 15 Aug 2007 21:03:29 +0600
> "Alexander E. Patrakov" <[EMAIL PROTECTED]> wrote:
>
>
>> And BTW, could you please test the 6.3 pre-releases of the CD? 6.2 is
>> dead.
>>
>
> I will if I can find them.
http://ums.usu.ru/~patrakov/test/lfslivecd-x86-6.3-r2014.iso
On Wed, 15 Aug 2007 21:03:29 +0600
"Alexander E. Patrakov" <[EMAIL PROTECTED]> wrote:
> TheOldFellow wrote:
> > If you use some little odd-ball PM, rather than, say RPM you will
> > end up spending more development effort on the PM than on the
> > LiveCD.
>
> I have tried privately (but together
On Wed, Aug 15, 2007 at 03:41:52PM +0100, TheOldFellow wrote:
> was spot on. Note also that neither fedora-6 nor ubuntu-7 would have
> anything to do with this box. So I'm impressed. (and I'd like to see
> instructions for loading the precompiled image onto the HD and making
> it bootable - I ca
lists wrote:
> the real reason that package managers are a bad thing, the bloated
> "requirements" of the meta packages in them. grab yourself a current
> debian install, and install KDE on it, minimal KDE without the kdeedu,
> games, development, pim package groups.
Easy:
aptitude install kdebas
TheOldFellow wrote:
> If you use some little odd-ball PM, rather than, say RPM you will end
> up spending more development effort on the PM than on the LiveCD.
>
I have tried privately (but together with Jeremy) to add RPM to /tools
in LFS and convert all instructions to spec files. Result: I
Jeremy Huntwork wrote:
> On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote:
>> I'll go on record as -1.
>
> I'm not going to push to get this into LFS. If the vast majority of
> those with a voice here are for PM in LFS, great. If not, great. :)
>
>> I feel we should mention it, prov
On Wed, 15 Aug 2007 00:02:07 -0400
Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Hello,
>
> As I've been giving some thought to what might make the LiveCD
> project more manageable, more open to community development and
> better all around, it occurred to me that our build method could be
> adjus
On Wed, Aug 15, 2007 at 03:29:47PM +0100, Alan Lord wrote:
> Jeremy Huntwork wrote:
> This is pretty much what I said in the "LiveCD users" thread you started
> on the 18th of last month on the general list...
>
> In fact here's my comments from that.
Yes, I recall that. And I remember agreeing
Jeremy Huntwork wrote:
> On Wed, Aug 15, 2007 at 02:56:45PM +0100, Alan Lord wrote:
>> Perhaps therefore, making the LFS PM friendly and then having a separate
>> project which would develop and provide on-going maintenance tools would
>> be a way to look at this... It too would also be a "learni
On Wed, Aug 15, 2007 at 02:56:45PM +0100, Alan Lord wrote:
> Perhaps therefore, making the LFS PM friendly and then having a separate
> project which would develop and provide on-going maintenance tools would
> be a way to look at this... It too would also be a "learning" tool
> demonstrating [p
[EMAIL PROTECTED] wrote:
> You could also consider using config.site like DIY Linux does. I tried it
> and I have had no problems with it.
>
Already used in the LiveCD for the purposes of compiling with sensible
architecture and optimization flags, as well as removing /usr/{man,info}
symlin
Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 08/15/07 07:20 CST:
>
>> I would love to see some sort of proper support for PM go into LFS, but
>> that all depends on the community...
>
> I'll go on record as -1.
>
> I feel we should mention it, provide links to the various altern
-- Original message --
> Alexander E. Patrakov wrote these words on 08/15/07 08:24 CST:
>
> > 1) add DESTDIR support to every package, instead of requiring each
> > packager to reinvent the same wheel; this also means the
> > "install-nokeys" target on the opens
On Wed, Aug 15, 2007 at 08:38:42AM -0400, George Boudreau wrote:
>I agree with Greg, Pacman is superior to Slackwares Pkgtools and does
> not depend on a quirk only available in tar <= 1.13..
>
I'm willing to give either a pkgtools-based PM or Pacman a try but a
definite decision on that cou
Randy McMurchy wrote:
> I do not see value in this at all. In LFS we are chrooted, so root
> is a given. In BLFS, one should never build as root as a matter of
> general principle.
The value for BLFS is that some packages may check some features of the
running kernel - and some checks are only po
Alexander E. Patrakov wrote these words on 08/15/07 08:24 CST:
> 1) add DESTDIR support to every package, instead of requiring each
> packager to reinvent the same wheel; this also means the
> "install-nokeys" target on the openssh page
Good point. Though I don't see it as being something that
Randy McMurchy wrote:
> Agreed, but then that vast majority must also come to agreement so that
> a vast majority of those decide on *which one* to use. We've already had
> about 5 people comment with 5 different PMs. It'll never happen
> (hopefully). :-)
>
The idea is not to put a concrete pac
Jeremy Huntwork wrote these words on 08/15/07 08:07 CST:
> On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote:
>> I'll go on record as -1.
>
> I'm not going to push to get this into LFS. If the vast majority of
> those with a voice here are for PM in LFS, great. If not, great. :)
Agre
On Wed, Aug 15, 2007 at 06:59:55PM +0600, Alexander E. Patrakov wrote:
> # This old version is the only one that won't clobber synlinks, e.g.:
> # someone moves /opt to /usr/opt and makes a symlink. With newer
> # versions of tar, installing any new package will remove the /opt
> # symlink and plo
On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote:
> I'll go on record as -1.
I'm not going to push to get this into LFS. If the vast majority of
those with a voice here are for PM in LFS, great. If not, great. :)
> I feel we should mention it, provide links to the various alternativ
George Boudreau wrote:
>I agree with Greg, Pacman is superior to Slackwares Pkgtools and does
> not depend on a quirk only available in tar <= 1.13..
>
Could you please explain in more detail? According to
ftp://ftp.slackware.com/pub/slackware/slackware-current/source/a/tar/tar.SlackBuild
Greg Schafer wrote:
> Alexander E. Patrakov wrote:
>
>> The first step would be to convert everything to DESTDIR-style
>> installation, and then adapt some existing (Slackware?) scripts to
>> package the result. IMHO, RPM would be overkill here.
>
> Pacman rules!!! :-) Oops, sorry, back on t
Jeremy Huntwork wrote these words on 08/15/07 07:20 CST:
> I would love to see some sort of proper support for PM go into LFS, but
> that all depends on the community...
I'll go on record as -1.
I feel we should mention it, provide links to the various alternatives,
and drive on. We are not a d
Shane Shields wrote:
> On 15 Aug 2007 Wed 11:25 am, Alan Lord wrote:
>> Jeremy - that sounds like a cracking idea but I strongly believe that it
>> should go much further than the LiveCD...
>
> Strongly agree
I would love to see some sort of proper support for PM go into LFS, but
that all depend
Alexander E. Patrakov wrote:
> Yes, I think this is good enough for now for the DIY reference build, if
> it is clearly stated that the patch is a workaround. Not sure about LFS
> - the x86 build is not affected, the x86_64 branch apparently (Jeremy:
> am I right?) should not be used (because it
Mike Lynch wrote:
> One of the nice things about the Solaris package manager is that *every*
> file installed is registered in a database (just an CSV file so no DB
> software
> like SQL needed) so it's easy to find out what has been installed. Package
> removal references the database to remove
Alexander E. Patrakov wrote:
> Greg Schafer wrote:
>
>> Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware
>> scripts could be adapted judging by the content at Jaguar Linux:
>>
>> http://www.jaguarlinux.com/
>>
>>
>
> Thanks for the link. Indeed, it looks that a lot of
Greg Schafer wrote:
> Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware
> scripts could be adapted judging by the content at Jaguar Linux:
>
> http://www.jaguarlinux.com/
>
Thanks for the link. Indeed, it looks that a lot of work has been
already done for us.
--
Alexander
Alexander E. Patrakov wrote:
> The first step would be to convert everything to DESTDIR-style
> installation, and then adapt some existing (Slackware?) scripts to
> package the result. IMHO, RPM would be overkill here.
Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware
scripts
On 15 Aug 2007 Wed 11:25 am, Alan Lord wrote:
>
> Disclaimer: Please take my comments as those of a lurker - rather than
> anyone with any actual authority on this subject.
I will also take the above disclaimer and apply it to myself
>
> Jeremy - that sounds like a cracking idea but I strongly be
Jeremy Huntwork wrote:
> package management
+1. This would also simplify production of the minimal CD (compile all
packages as a side effect of building the full CD, then install only
needed ones), and reduce the size of the main CD (because we don't want
to ship, e.g., headers for gtk+ - so le
Jeremy Huntwork wrote:
> Hello,
Hello
> Essentially, the LiveCD is a distribution. But it is a distribution
> without something that nearly all others have: package management. Up to
> now, there hasn't really been a need. But, if the CD incorporated PM at
> its very heart, developers could
79 matches
Mail list logo
