Bootscripts - Why combining is a bad thing

Gerard Beekmans gerard at linuxfromscratch.org
Tue May 30 10:29:37 PDT 2006


Randy McMurchy wrote:
> What text will be in the LFS book. "Here is the current LFS tarball
> to install after you complete LFS. It also has BLFS bootscripts in
> it, but they probably aren't current, so you'll need to get a
> different tarball for BLFS."  :-(

Maybe I wasn't clear on the combining of things. Perhaps an oversight.

It's not perse the intent to combine everything into one tarball 
release. I agree that with bootscripts it's a bit of a different scenario.

We could still decide to at least place all the bootscripts in the 
bootscripts SVN repository and generate two tarballs (one for LFS, one 
for BLFS) when changes are being made. One way to look at it is 
splitting off the "software developments" aspects from the "book 
developments."

Of course you raise a point that if you need to update a bootscript, 
this new group needs to deal with that in a timely manner.

As such it only makes sense to me that all book editors get write access 
to the repositories. It's not meant to give people sole control over 
them. We can collaborate. I can see you, Randy, get commit access so 
when you update your package, you can update or create its bootscripts, 
release a new blfs-bootscripts tarball along with the package update. Or 
if you don't have the time to create a blfs-bootscripts release, 
somebody else in the group can do it.

What I personally am after is putting these components and source codes 
in one central place from where one or more tarballs can be released as 
we deem necessary.

Likewise, putting all the udev rules together in one package might end 
up undesirable. But they can be managed and maintained by people who are 
best qualified and they can then deal with releasing two tarballs (one 
for LFS, one for CLFS, maybe BLFS too). Those are logistical things in 
the end and not the primary problem at this time.

As Matt put it (slightly edited):

...with subversion's branching capabilities it's trivial for this group 
to ensure that the versions in LFS/BLFS/CLFS differ *only* in the way(s) 
they need.

To summarize again, just to be sure it's clear: the goals as I 
personally see and meant them is *not* to put everything into one single 
  tarball. That just is not feasible with some of the things we're doing.

-- 
Gerard Beekmans

/* If Linux doesn't have the solution, you have the wrong problem */




More information about the lfs-dev mailing list