Armin K. wrote: >>>>> We can do this for 7.5. The rule here is that we can update point >>>>> versions but not major or minor versions. >>>> >>>> Couldn't it be the same for blfs, for almost all packages? >>> >>> That's worthy of discussion. Perhaps end packages and not libraries >>> would be amenable to this type of rule. I'm hesitant to update >>> libraries right now because of possible breakages of programs already >>> marked as lfs75_checked. For the few packages that are marked >>> lfs75_built, then there is no good reason not to update. >>> >>> Is that a reasonable compromise?
>> I'd prefer not to touch anything (especially modify dependencies at this >> late cycle) unless it's really worth upgrading, ie security issues, >> feature required by some other packages present in newer version but not >> older, etc. > Also, there's a note in LFS telling people to use latest kernel 3.13.x, > so it matters little. API headers don't change much (if all) anyways. Well there was a pretty big change in the kernel from 3.12 -> 3.13 that allowed pftables. Agree that API doesn't change for point versions. The note is in LFS Chapter3, but we also have a wget-list and md5sums file that isn't updated unless we update the book. I'd prefer to have that up-to-date at the -stable release. What I'm suggesting is that packages at the end of the chain such as goffice and firefox could be updated within the package freeze period without harming the integrity of the overall book if they are built and tested using lfs75 components. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
