> 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
--
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
