Ken Moffat wrote:
On Tue, Apr 28, 2015 at 10:58:26AM -0500, Bruce Dubbs wrote:
If I update a package version, e.g. for biber-2.0, I will build it
both on a 7.7 system, using gcc-4.9.2, and also on a newer system
built with gcc-5. And tag it for both.
The first priority for everybody should be to keep a working system.
Anybody who updates to gcc-5 in-place is likely to have problems,
particularly in C++.
As you say, my approach does reduce our ability to commit upgrades.
Perhaps there is a better way of doing this ?
Just use the gcc tag and delete the 7.7 tag. Until we do a complete rebuild
of BLFS using gcc5, the -dev book will be in an inconsistent state, but
that's the nature of -dev.
I was thinking more of Fernando's problem - I've persuaded him to
back out gcc5 to reduce problems with his current system. So, once
things are tagged with gcc5 he doesn't want to upgrade a version and
drop back to a 7.7 tag.
Me, I can run multiple systems on different machines. I'll be
starting a fresh build sometime this week on one of my main
machines: for that the prime purpose will be to test biber-2.0 with
gcc5, on texlive-2014. By the time texlive-2015 comes out, that
build will be redundant. That's fine by me.
I agree that the most comprehensive solution is to have two systems, one for 7.7
with gcc-4.9.2 and one for gcc5. If a package is built on both, then mark for
both. However that's not strictly necessary. Either one is fine for an update
of the -dev book. Just mark accordingly.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
