> From: Christopher Gregory <[email protected]> > To: [email protected] > Date: Thu, 07 Aug 2014 04:11:46 +1200 > Subject: Re: [blfs-dev] When naming versions of gcc > > 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.
- a redundant sentence already. > 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 Yet you have done precisely that in your first para above, and proceed to do it all the way through the rest of your note. > what I have written about or what I was > thinking as you do NOT know. > > It is a very VALID point that I made. Depends on what point you're referring to. Original raised query: yes, I'd agree it's of course perfectly reasonable to ask the question - and never said anything to the contrary. Original suggested 'solution': thought wasn't the right one - and said so. You got a problem with that? > 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? > Nobody said that you did or said that you didn't. Calm down. Nobody's talking about that. > 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 Not in your spelling of 'whether' - "worst spell of weather we've had in a long time". > in what I have said. > Ref above to your other self-defined correctness. Depends on what part(s) of what you said, are you referring to. > To use your own words back at you, the cruft was already added to the > page. > Not 'the cruft' that was being referred to. You are not currently of sound understanding - so many capital letters and crayons. > Do NOT USE Easy, tiger ... . > what I have suggested as a means to further a personal grudge > that you obviously have against Armin. > - more childish rubbish. Ref again your "Do NOT try" above. Don't assume that your horizons - e.g. interpretations, mental processes - define everyone else's. > I DO NOT LIKE THAT KIND OF PETTINESS. > > Don't drag me into it EVER again. > You weren't dragged in to anything. Again, calm down. You've if anything "drag"ged yourself around. Shrieking in caps all over the place. > With regards to building all packages against what is in an LFS build, > that is EXACTLY what I am doing. It's not "EXACTLY": you're also talking garbage, for at least one thing. rgds, akh > > Christopher. > > -- -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
