On 08/06/2014 02:44 PM, akhiezer wrote: >> Date: Wed, 06 Aug 2014 14:33:53 +0200 >> From: "Armin K." <[email protected]> >> To: BLFS Development List <[email protected]> >> Subject: Re: [blfs-dev] When naming versions of gcc >> > . > . >> >> If (new) compiler restrictions/rules caused an error, then it will be a >> problem with any later version. >> > > > Not really - not for _any_ later version: it's not a _problem_ for > downstream/blfs if e.g. lame at some point adjusts its code such that the > patch is not needed. > >
We are speaking about gcc, not lame. If a version of lame was released 6 years ago and gcc-4.6.0 introduced a build failure, that same build failure will be present with gcc-4.9.0 in the same version of lame released 6 years ago. >> Debian uses gcc-major-minor to indicate that patch fixes a problem that >> occours with gcc feature additions/improvements (increased minor version). >> > > > Yes, but that all becomes unnecessary if e.g. lame code adjusts such that > the patch is not needed at all. > > > If for some reason, the blfs lame page wants to say that a patch is for > gcc 4.9.0 & 4.9.1 then sure: but a blfs release is based on a single lfs > release, that has a single gcc ver; so such a comment in the blfs lame > page - talking about multiple gcc versions - is kindof an aside. > > Sounds fair, but that would need adjusting again if new version of lame doesn't come out, but new version of gcc does. So why bother using full version if you are (maybe) going to change it later anyways. >>> >>> For this case, I thank Christopher and will bump the version. >> >> >> >> -- >> Note: My last name is not Krejzi. >> > > > -- > -- Note: My last name is not Krejzi.
signature.asc
Description: OpenPGP digital signature
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
