On 02/21/2014 05:44 PM, 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. >
Kernel gets released often, so even after the book releases, you'll have new kernel version and if anyone cares about the note, they'll use newer kernel instead of the provided one and get the same result - wrong md5 sum and such. > 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 I don't have anything against that as long as they don't install libraries that *others* link to (goffice is that, but gnumeric isn't) and if dependencies don't change (major upgrades or switch additions/removals). So I believe even you said that such should be bugfix (minor) upgrades, and not feature (major) upgrades. But note that some packages even on minor upgrades can add/remove features (but very few do that) so I don't know how's that going to work. I believe we need a policy to exactly define what exactly "package freeze" means. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
