> Date: Fri, 21 Feb 2014 14:02:04 -0600
> From: Bruce Dubbs <bruce.du...@gmail.com>
> To: LFS Developers Mailinglist <lfs-dev@linuxfromscratch.org>
> Subject: Re: [lfs-dev] Outstanding tickets
>
.
.
> >
> > Seems a bit over-obvious to say, but: isn't it better to freeze the lfs
> > part and then - say approx 2 weeks later - freeze the blfs part; lfs is,
> > after all, the foundation for the blfs part.
>
> The problem is that no matter how we do it, upstream keeps making new
> releases.
When in pre-release stage, by definition you're (about to be) making a
snapshot, and so new package versions from upstream should be less of a
concern - outwith security/major-bug fixes in the usual way. Does anyone
have regrets if a new minor minor version of e.g. grep is released within
2 weeks - or 2 days - after/before book release.
It seems that the goal of having a release with every package completely
up-to-date on release day, is still aimed for in some quarters: whereas
that's not really the goal of proper release engineering, where a much more
central & major goal is to have a set of components (packages, versions)
that are verified to work well together. And if that means that 6 packages
are '"out of date"' (again, outwith security/&c issues) then so what?
> I'm fairly confident that LFS is pretty solid. If it were
> only LFS, the 'freeze' would be shorter. What we really need to do is
> freeze development tools and libraries. The likelihood of something
> like a grep upgrade affecting the rest of LFS or BLFS is pretty small.
Yes, the 'likelihood'; & everyone understands that. But that's not the
point: the point is that if you change LFS, then all of the '&lfs75_...;'
tags in BLFS are now _not true_; and the corresponding rendered book text
that you are publishing, is also now _not true_ .
For each of them to become true again, each would need to be re-tested. So
by making an unnecessary change to lfs, one would be rendering wasted a
non-trivial percentage of folks' blfs testing; and simultaneously asking
them (at least implicitly) to re-test against the new lfs.
If the policy and practice is to make changes to lfs and not re-test blfs,
then that should be reflected upfront in the '&lfs75_...;' tags, and in the
corresponding rendered book text that is being published: say upfront in
the published rendered book - & elsewhere as applicable - that, "we changed
this, this, and this, in lfs, and didn't re-test blfs; but it should be OK".
But in any case, to make changes in the foundations, and assume that the
structure on top of it 'should be OK', is not only asking for trouble,
but actively seeking it out - or sitting waiting for it to arrive. That
may be acceptable for personal builds; but surely not for pushing out to
others - unless at least you're telling them upfront what you have done
and what is your policy on the matter.
> On the other hand, a change in gcc would require complete retesting.
>
(Am saying the above while aware that am not doing such testing directly;
we just build too-different an os here. However, looks like there may still
be that gmp/mpfr/mpc issue for gcc build - per Hazel Russman thread back
in ca Oct/Nov 2013: might open as separate thread.)
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
