This is under the premise that the udev configs are stored in a package.
How about possibly tackling them like we do the bootscripts - the udev
rules are in SVN, thus they are always checked out in our local copies
when we do 'svn co LFS/trunk'
--
http://linuxfromscratch.org/mailman/listinfo/l
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> I'm not sure if this is possible with the XML toolset, but it may
>> work to grab the values of &udev-config;.tar.bz2 and
>> &udev-config-url;. Run wget on the second, un-tar the first, and
>> then gra
Bryan Kadzban wrote:
> Gerard Beekmans wrote:
>> If a diverging is needed then we may just need to branch it.
>
> Yeah, that may have been smarter.
>
>> It's not *the* solution but it sure would keep things easy for us. It
>> gets complicated otherwise to rememer.
>
> I'm not sure if this is pos
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gerard Beekmans wrote:
> If a diverging is needed then we may just need to branch it.
Yeah, that may have been smarter.
> It's not *the* solution but it sure would keep things easy for us. It
> gets complicated otherwise to rememer.
I'm not sur
> them. That way if the book and those packages ever diverge (e.g. as
> udev-config has recently; the current udev-config trunk won't work with
> the current BOOK trunk), you don't get the wrong scripts or rules files.
>
That's what I was getting at. However we may want to safe guard against
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gerard Beekmans wrote:
> ...Develop/maintain an actual bootscripts package and during the
> generation of the LFS book, extract the scripts and include into the
> book.
>
> That does mean that anybody who wants to build the LFS book needs to
> c
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Gerard Beekmans wrote:
>> I think the consensus we're trying to reach is what to do with the
>> bootscripts if we do add them back to an Appendix as Bruce
>> suggested. Do we still install the bootscripts the current way or
>>
TheOldFellow wrote:
> I really like what Bruce has done.
Thanks.
> The udev scripts (and any other
> package's configuration that is sufficiently complex to need an example,
> even in BLFS) do need to be added too. Can the packages bootscripts not
> be auto-generated from the book XML (or pr
> even in BLFS) do need to be added too. Can the packages bootscripts not
> be auto-generated from the book XML (or preferably, vice versa) - to make
> maintenance easier?
The "vice versa" method is how it's done at the moment and what Bruce
has done. Develop/maintain an actual bootscripts pac
>> I think the consensus we're trying to reach is what to do with the
>> bootscripts if we do add them back to an Appendix as Bruce suggested.
>> Do we still install the bootscripts the current way or does the
>> appendix become a *replacement* for the bootscript package installation
>> in chapter
Gerard Beekmans wrote:
>> OK, take a look at http://www.linuxfromscratch.org/~bdubbs/lfs-book/
>
> Looked at it and gave it the last few days to think about it some more.
>
> I'm a bit conflicted about this but there may be an easy solution to it.
>
> No matter what ends up happening, the script
> OK, take a look at http://www.linuxfromscratch.org/~bdubbs/lfs-book/
Looked at it and gave it the last few days to think about it some more.
I'm a bit conflicted about this but there may be an easy solution to it.
No matter what ends up happening, the scripts definitely can be better
document
Gerard Beekmans wrote:
>> Do you want me to start on adding this to the book as Appendix D?
>
> Can I see a finished renderring not quite part of SVN yet.
OK, take a look at http://www.linuxfromscratch.org/~bdubbs/lfs-book/
I did not change the version number, so it still says SVN-20080423, but
13 matches
Mail list logo
