> Date: Wed, 06 Aug 2014 14:30:02 -0500 > From: Bruce Dubbs <[email protected]> > To: BLFS Development List <[email protected]> > Subject: Re: [blfs-dev] When naming versions of gcc > > akhiezer wrote: > > > 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). > > Jumping into the middle here. I haven't read the whole thread yet, but > I think you guys are discussing svn. When we release the stable > version, then the stable gcc is appropriate. And yes, we intend to > check every package of both lfs and blfs before a stable release. > > That said, it may be appropriate to say "... with some versions of gcc." > > Is the problem due to the package or is it due to gcc? If it's a bug in > gcc, 4.9 and 4.9.1 may cause the problem, but it might get fixed in > 4.9.2. We certainly can't check every package with multiple versions of > gcc. > > Is the problem due to a bug in the package that isn't identified until > some version of gcc highlights it? Possibly. > > The only thing that's really important is to say that we found a problem > and that this sed or patch or other procedure fixes it. >
AIUI: Here's a worked example: ---- * At a given point in time, lfs svn has moved to gcc 4.9.0, and a short-ish while later in blfs svn the lame page is getting updated - just as & when suits the devs (ie in the ~usual ~'laissez-faire' sequence, and not necessarily prompted directly or 'urgently' or in a hidebound manner, by the gcc change in lfs) - and it needs and so uses a patch that has been necessitated by gcc going from 4.8.x to 4.9.0 ; so the lame page's text references that patch, usually by named url; and the lame page's text might also mention the gcc version in the lame-page-text blurb about the patch. (If the 'patch'/'fix' is done as a sed or whatever in the text of the lame page, then the literal patch _file_ doesn't exist; and so the only two components are the page text and the 'patch'/'fix' content.) * So that's fine. The lame page in blfs-svn happens to have been brought into sync with lfs-svn wrt gcc stuff. * Then lfs svn bumps gcc to 4.9.1 (dem damn pesky devs, scoob!), and so again in the usual seq, blfs svn lame page is now sitting at an out-of-sync state _wrt_ the gcc stuff in lfs-svn. * That's fine, of course - it's svn. * Even if there's no new lame version, somebody might at some point go and check to see if the lame page compiles ok against lfs svn (with gcc 4.9.1) and if it still needs the patch that was used earlier when compiling against the earlier lfs svn that had gcc 4.9.0 . And similarly if there _is_ a new lame version. * The above svn process is of course slightly 'laissez-faire' (that's not a crit, just shorthand). But at some point in the run-up to a blfs-rel, and because blfs rel is based on lfs rel, so you _do_ want to proactively verify that lame in blfs svn/rc is ok with the gcc in lfs rc/rel. * And so overall, at least at some point, if lfs changes from gcc 4.9.0 to 4.9.1, you're going to want to deal with the lame page that makes reference to gcc 4.9.0 in patch content, patch name, and lame page text. * If lame no longer needs that patch, then of course all three components get un-hooked from the new lame page. But if lame does still need the patch, then what do you do for each of the three components? The patch content of course stays the same, by definition ( - else it's dealt with as a new patch, also by definition). So that leaves the patch name and the page text. The page text would principally reference gcc 4.9.1 and _perhaps_ may note as an aside that the same patch was needed/introduced for gcc 4.9.0 : but the page text surely wouldn't just say e.g. that the patch is needed for the gcc 4.9.x series; the reasons why can be revisited if necessary. So that leaves the patch name. Some folks/projects just carry forward and use the original patch name: it's a commonly understood idiom; and folks are fine with it. Whereas some folks/projects do rename the patch to reflect the actual version (in this example) of gcc that the patch is being used for: this is often the case in projects where e.g. their rcs deals with file renames automatically, efficiently and in a way that's easy for the user to work with; and the projects have easy ways of mapping patches to what is using the patches. Either approach is fine. And neither of them throws information away pointlessly and just says to the reader, "oh it's some/all versions of gcc 4.9.x that this patch is for". Likewise they don't just only say _when_ - for what version - a patch was introduced: they say explicitly that the patch _is_ for gcc 4.9.1 ; why not just give as the prinicpal piece of info that it _is_ for 4.9.1 , and have any other stuff (like, it was intorudced at 4.9.0) as at most secondary info. -- Hopefully that at least partly helps clarify. rgds, akh > -- Bruce > -- -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
