Jeremy Huntwork wrote:
Jim Gifford wrote:
Is this acceptable to all.
The bootscripts package and udev rules seem to me to be two separate
issues here, and at least until there's shown to be some benefit of
merging those two together, I'd prefer to keep them separate. So far,
most seem agreeable to making the udev rules their own entity - one
package/repo for all projects. That has seemed to reach a consensus, but
we still need to hear Alexander's comments on it, so let's give him the
time he needs. (I think he's sleeping, atm.)
Just wanted to add another +1 for merging the rules between projects.
Not that it matters since it's already in the works. :-)
The suggestion to merge LFS and BLFS bootscripts into one package is
really another topic, and something that I wanted to hear more
discussion on, perhaps from the current maintainer himself. DJ, you have
any thoughts?
--
JH
Sorry for the late reply. I avoided this thread for a couple of days,
seeing it's size and expected flame fest...not to mention the topic was
a little misleading. :-)
I am fine with merging the bootscripts if the community wants it. That
is conditional on the ability to create an auto generated tarball (not a
big deal). Also, the editors must have access to their respective
directories under the bootscripts repo (same as the requirements for
udev). Again, IIRC, it was not a big deal to make the post commit hook
on the BLFS book's changed tarball date. I haven't seen the existing
one, but an anonymous co and export (don't go mucking around in the repo
directly) on belgarath each time the bootscripts date changes seems it'd
work well. Syncing them between the books for a single tarball is where
it would be difficult. Actually, even that shouldn't be bad. Only
generate the tarball if it's not already there. I'm not sure, off the
top of my head, how to handle changing the bootscripts date in the other
two books.
Now, when this was mentioned to me previously, I did not know that this
included BLFS's scripts. This can present a problem for release cycle,
unless we can be *very* sure that BLFS will not need to add another
bootscript after LFS reaches release. Generating the official book
tarball can be added to the LFS release checklist to minimize this
possibility. The same goes for CLFS scripts, though they'll change less
frequently. The scripts for CLFS are lfs-bootscripts + CLFS additions
for additional hardware. As it is right now, changes that go into LFS
must be duplicated in CLFS's repo, or a patchset kept current (and
potentially the reverse). To me, that merge is a no-brainer.
Now merging with udev... I didn't like it last time it was mentioned,
but I might have been a little hasty in my reply. It might save a
moment or two downloading only one tarball and installing in one shot
(maybe even a little bandwidth too, though it would be a negligible
amount). This would require a change to the LFS book, CLFS?. It's not
logical for the bootscripts and udev packages to be merged with the
installation of the two in different chapters. Additionally, a skeletal
set of config files could be installed and a user expected to make
changes to them, as suggested by Bruce previously. If those could
happen, and the post commit hooks worked out, then I'd now love to merge
it all into one happy lfs-etc-config package.
So, there are my thoughts. :-)
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
