Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
Fernando de Oliveira wrote: Em 20-02-2014 23:00, LFS Trac escreveu: #3505: linux-3.13.4 --+ Reporter: bdubbs@… | Owner: lfs-book@… Type: task | Status: new Priority: normal| Milestone: 7.5 Component: Book |Version: SVN Severity: normal| Keywords: --+ New point version. 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? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
On 02/21/2014 03:51 PM, Bruce Dubbs wrote: Fernando de Oliveira wrote: Em 20-02-2014 23:00, LFS Trac escreveu: #3505: linux-3.13.4 --+ Reporter: bdubbs@… | Owner: lfs-book@… Type: task | Status: new Priority: normal| Milestone: 7.5 Component: Book |Version: SVN Severity: normal| Keywords: --+ New point version. 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? -- Bruce 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. -- 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
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
On 02/21/2014 05:29 PM, Armin K. wrote: On 02/21/2014 03:51 PM, Bruce Dubbs wrote: Fernando de Oliveira wrote: Em 20-02-2014 23:00, LFS Trac escreveu: #3505: linux-3.13.4 --+ Reporter: bdubbs@… | Owner: lfs-book@… Type: task | Status: new Priority: normal| Milestone: 7.5 Component: Book |Version: SVN Severity: normal| Keywords: --+ New point version. 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? -- Bruce 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. -- 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
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
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
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
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
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
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
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
Armin K. wrote: I believe we need a policy to exactly define what exactly package freeze means. It means don't upgrade a package unless we talk it over and agree that it can be upgraded without creating additional work during the release testing period. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
On 02/21/2014 06:05 PM, Bruce Dubbs wrote: Armin K. wrote: I believe we need a policy to exactly define what exactly package freeze means. It means don't upgrade a package unless we talk it over and agree that it can be upgraded without creating additional work during the release testing period. -- Bruce Yeah, that seems the easiest thing to do :P I accept. -- 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
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
On 02/21/2014 06:02 PM, Bruce Dubbs wrote: 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 Add libreoffice to that list too. It's minor update anyways and I didn't notice any big change. One could argue to update gdk-pixbuf too since it contains bugfixes, but I don't think any of these is important at the moment. Same goes for webkitgtk-2.2.5. -- 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
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
On Fri, Feb 21, 2014 at 08:51:55AM -0600, Bruce Dubbs wrote: Fernando de Oliveira wrote: Em 20-02-2014 23:00, LFS Trac escreveu: #3505: linux-3.13.4 --+ Reporter: bdubbs@… | Owner: lfs-book@… Type: task | Status: new Priority: normal| Milestone: 7.5 Component: Book |Version: SVN Severity: normal| Keywords: --+ New point version. 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? -- Bruce I'm somewhat reluctant to update even end packages, unless there is a wrthwhile fix (either a vulnerability fix, or a documented fix for a problem). For libraries and toolkits, particularly once they have been tagged, my general opinion is that they should wait until after the release - again, unless there is a major fix [ and if there is, all tags are off ]. On that basis, no to updating x264 (#4732). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Couldn't it be the same for blfs? [Was: ... #3505: linux-3.13.4]
On 02/21/2014 10:12 PM, Ken Moffat wrote: On Fri, Feb 21, 2014 at 08:51:55AM -0600, Bruce Dubbs wrote: Fernando de Oliveira wrote: Em 20-02-2014 23:00, LFS Trac escreveu: #3505: linux-3.13.4 --+ Reporter: bdubbs@… | Owner: lfs-book@… Type: task | Status: new Priority: normal| Milestone: 7.5 Component: Book |Version: SVN Severity: normal| Keywords: --+ New point version. 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? -- Bruce I'm somewhat reluctant to update even end packages, unless there is a wrthwhile fix (either a vulnerability fix, or a documented fix for a problem). For libraries and toolkits, particularly once they have been tagged, my general opinion is that they should wait until after the release - again, unless there is a major fix [ and if there is, all tags are off ]. On that basis, no to updating x264 (#4732). ĸen My opinion (given that it matters here) is more or less the same. See lfs-dev response. -- 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
