> Date: Thu, 27 Mar 2014 17:41:37 -0500
> From: Bruce Dubbs <bruce.du...@gmail.com>
> To: LFS Developers Mailinglist <lfs-dev@linuxfromscratch.org>
> Subject: Re: [lfs-dev] Thoughts about LFS and systemd
>
> akhiezer wrote:
>
> > And in any event, you're still aiming at adding an "ifs'n'buts" layer to
> > the lfs-main book - the type of thing that has been argued against many
> > many times.
>
> Yes, if we end up doing this, it is a major change from our traditional
> methodology. It would, in fact, be LFS 8.0.
>
But still, you're running too much of a risk of main branch becoming a
convoluted - epicycles 'pon epicycles - mess if it is 'exposed' too-directly
to e.g. a still-rapidly-changing 'upstream' (which in this case happens
to be the sysd side of things). Instead, you'd normally keep lfs-main
and lfs-sysd as separate branches, and merge them into a third branch,
lfs-combined. ((Aside: of course, in time, the branch names might be
revised/remapped.))
Part of the reason that comparisons of lfs-main and lfs-sysd can be done
just now quite readily, is precisely that they are two clearly separate
branches. Could you still do such clear comparisons if you have only
lfs-combined and lfs-sysd as the two branches? E.g. if you stop having
a separate lfs-main and replace lfs-main with lfs-combined directly,
then are you sure that you - and indeed others - will be able to auto-
(or at least efficiently) and accurately generate the equivalent of a clear
lfs-main book from lfs-combined, by setting a param, say USE_SYSTEMD=0 ?
Are you also reasonably sure that there aren't any hard blocks going to
happen: the two projects - lfs-main and lfs-sysd - may be readily-entwinable
just now in their respective present states; are you sure enough that that
will be the case for at least, say, the next two years? If you're not sure
enough of that, then even more reason to have lfs-combined as a third,
separate branch.
It's also an important point that having lfs-main and lfs-sys as clearly
separate branches, helps 'keep the peace' - 'good fences / good neighbours'
- and helps keep respective groups 'happy': each can get on productively
with doing the respective works that they enjoy; and as a fairly direct
by-product of that, one can see clearly how readily can the two branches
be merged into the 'lfs-combined' branch/project.
So, having lfs-{main,sysd} as separate branches, is not a pointless
unnecessary burden: on the contrary, it's having them clearly separate,
that contributes in large part to lfs-combined being so readily do-able.
> > I do think that the idea is of interest: but it's really a candidate for
> > a separate branch/project.
>
> So far I've just added some packages that sysd needs but doesn't change
> the essence of the book a lot.
But those packages would auto- drop-out if a user is building/following the
non-sysd track of the book, right? You _would_ tell them that they don't
need to build/do those packages/steps: or would you let a few 'innocuous'
ones slip through unmentioned and have users build them anyhow - e.g. for
devs' convenience if you hit (as is reasonably predictable) a bind. IOW,
if it's convenient for devs, would you quietly have non-sysd users building
stuff that's really genuinely only required for the sysd side?
> Adding sysd is where things really start
> to change. After I do some work in my sandbox, I may indeed create a
> separate branch, which, btw, is not really much more than the git
> method: cd ../../branches; svn cp ../trunk/BOOK experimental
In case that last point is re the earlier remark about git branches being
'inexpensive': it wasn't said that the inexpense was just concerning the
creation of branches; but rather, overall - and in particular central
things like rebasing.
The activity that you're embarking on, would almost everywhere else be done
on a separate branch. I've encountered - whether directly or indirectly -
only very rarely, projects where it's decided to essentially refactor the
project directly on the main branch.
You say that if it doesn't work out then things can just be reverted. That's
far easier to do on a separate branch - or indeed just blow the branch away
- than it would be to essentially, in practice, have to cherry-pick which
commits you want to revert from a main branch ... 'cos you'd earlier gone'n
decided at some point, for some reason, to do 'experimental'-branch-type
work, on main trunk ... .
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
