On Wed, 2014-08-06 at 15:15 +0100, akhiezer wrote: > > Date: Wed, 06 Aug 2014 15:39:40 +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. > > > Spare me the crap: we are talking in the context of the particular > example that Christopher gave; hence the continued mention of lame as the > particular-case example. That's plainly obvious to anyone, so cut the crap > and stop continuing your habit of trying insinuate dishonestly that folks > have got a different viewpoint/stance from what they plainly have. > > > Do you understand the concept of discussing a point using a particular > concrete example. > > > > 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 > > > "> We are speaking about gcc, not lame." fkin idiot. > > > > doesn't come out, but new version of gcc does. > > > Then in b/lfs you typically would at least verify at some point - e.g. next > time the lame page is under consideration - whether the patch is still > needed or not: how do you _know_ that the new gcc ver doesn't obviate the > need for it; d'you just assume that it's likely, or what. > > > This perhaps raises the general point: if gcc bumps from 4.9.0 to 4.9.1 , > then does b/lfs verify that: for any packages whose own package-versions > have not yet changed, and that were using patches necessitated by 4.9.0 ; > are the patches still needed for the respective packages for 4.9.1 . > > > Similarly, does blfs recompile all packages against the core toolchain in > lfs, for a given b/lfs pair of releases? (Not every distro does that kind > of thing). > > > > So why bother using full > > version if you are (maybe) going to change it later anyways. > > > > > You aim for the level of accuracy of your book notes, as you wish; > it's noted. > > > But Christopher's original 'problem' is a complete non-problem. > > > At any given time, the lame page is essentially only referencing one > particular version of gcc. If it needs a patch for 4.9.0, and then gcc > goes to 4.9.1 in lfs, that means that the lame page is now out-of-sync with > lfs: and when the lame page gets updated - whether same/new lame version, > but against gcc-4.9.1 - if the patch is not needed then you remove the > comment; and if the patch is still needed then you bump the comment to ref > gcc-4.9.1 ; and if you somehow for some reason want to mention that the > patch has been needed for 4.9.0 as well as still now for 4.9.1, then fine, > but it's a secondary consideration. > > > Therefore, the 'problem' of 'having' to update, is a non-problem: you > _want_ to update anyway. What you/Christopher seem to be mooting, is to > intentionally add essentially cruft to page(s). > > > > hth, > > akh > > > > > > --
Hello, I am not going to let that comment go. Adding cruft to pages? Get your head out of your a** and actually THINK about my perfectly reasonable REQUEST/SUGGESTION. Do NOT try and second guess what I have written about or what I was thinking as you do NOT know. It is a very VALID point that I made. Actually take a look at other sites around and you will see that 4.9.x is VALID. I was not the one who added a PARTICULAR version number to a description field was I? I had already thought about all the possible reasonings for it being added in the first place. Weather you like it or not, I am CORRECT in what I have said. To use your own words back at you, the cruft was already added to the page. Do NOT USE what I have suggested as a means to further a personal grudge that you obviously have against Armin. I DO NOT LIKE THAT KIND OF PETTINESS. Don't drag me into it EVER again. With regards to building all packages against what is in an LFS build, that is EXACTLY what I am doing. Christopher. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
