> Date: Wed, 06 Aug 2014 16:54:47 +0200 > From: "Armin K." <[email protected]> > To: BLFS Development List <[email protected]> > Subject: Re: [blfs-dev] When naming versions of gcc > > On 08/06/2014 04:15 PM, akhiezer wrote: > > [post removed because of personal insults]
The post was dealing in part with your attempted nonsense. Don't try your stunts if you can't take a bit of opposition to them. > > To akhiezer: > > Please leave personal insults out of this. For the sake of this mailing > list, I'll admit that I was wrong and let it be as it is. You win. ( - childish rubbish; is there something about August-time for you ... ) > Please don't reply to the part below. > > To everyone that's interested in this besides akhiezer: > > What I said still stands, but I'll try to say it one more time: > > If a package needs patching for an issue that was introduced by gcc > feature release, then it's a bug in a package and it needs to be fixed > in a package for possibly _every next release_ of the gcc compiler > (untill a new version of package comes out). In order to avoid > _renaming_ (creating additional, unnecessary work) patches, you could In practice, that doesn't arise, for the reasons and scenarios outlined earlier. It's a non-problem. > use a term which indicates the bug was introduced by gcc feature release > (4.9). > The converse is that your nomenclature is then implying that the thing is true for the whole 4.9.x series: which is not necessarily true. > If a package fails to build because of a compiler issue (something got > broken when adding new features and stuff), the compiler should be fixed > or in the worst case, the issue should be worked around in a package. > That still indicates that issue was introduced by gcc feature release > and it still would be easier to use major-minor version instead of full > version because one can't be sure in which compiler release the bug will > be fixed (4.9.1, 4.9.2, 4.9.1328 (joke), 4.10.0 or whatever). > > The suggestion is just to avoid unnecessary renaming of the patches. > > (As a side note, we also have packages which got fixed for old versions > of packages that's still present with latest releases of the packages > they were fixed for, yet we don't update that to say "latest version in > lfs book", but rather keep the "first version it got introduced with".) > Yes, that's commonly how it's done; and a commonly-understood idiom. Again, and either way, you've got a non-problem here. hth, akh -- -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
