Bruce Dubbs wrote: > 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.
Here are the packages updates we might consider: xfburn gptfdisk gparted mpg goffice gnumeric -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
