> Date: Mon, 17 Feb 2014 12:58:05 -0300 > From: Fernando de Oliveira <fam...@yahoo.com.br> > To: BLFS Development List <blfs-dev@linuxfromscratch.org>, > Subject: Re: [blfs-dev] lsb_release configuration [Was: ... Iced Tea 2.4.1 > and iced tea 2.4.5 sed unknown option to `s'] > > Em 17-02-2014 11:21, akhiezer escreveu: > >> Date: Mon, 17 Feb 2014 09:10:17 -0300 > >> From: Fernando de Oliveira <fam...@yahoo.com.br> > >> To: BLFS Development List <blfs-dev@linuxfromscratch.org> > >> Subject: [blfs-dev] lsb_release configuration [Was: ... Iced Tea 2.4.1 and > >> iced tea 2.4.5 sed unknown option to `s'] > >> > >> Em 17-02-2014 07:53, Fernando de Oliveira escreveu: > >>> Em 17-02-2014 03:47, m...@pc-networking-services.com escreveu: > >> > >> > >>>> Thanks for all the effort. As requested the output is: > >>>> lsb_release -ds "7.4" (the " are displayed in the output) > >>>> lsb_release -is n/a > >>>> > >>>> Not exactly sure what you wish me to try. > >>>> > >>>> I have no problem with attempting to install a later version if needs be. > >>>> > >>>> Please let me know what to try. I did install the version listed as > >>>> stable in the 7.4 book. It was that one which I replaced the / with a % > >>>> sign. Was the only way to get it to build, and hence why I am not sure > >>>> if > >>>> it was a successful build or not. > >>>> > >>>> Regards, > >>>> > >>>> Christopher. > >>>> > >>> > >>> > >>> I think I know what happened. You forgot or did not properly > >>> > >>> http://www.linuxfromscratch.org/lfs/view/7.4/chapter09/theend.html > >>> (before doing the following as root, backup, if you have them, the two > >>> files, just for later comparison, so you will see the problem): > >>> > >>> echo 7.4 > /etc/lfs-release > >>> > >>> In the following, replace <your name here> by what you want the codename > >>> to be. In may case, it is set by jhalfs to "lfs-jhalfs". In your case, > >>> you can use christopher, lfs-christopher, anything you want. > >>> > >>> cat > /etc/lsb-release << "EOF" > >>> DISTRIB_ID="Linux From Scratch" > >>> DISTRIB_RELEASE="7.4" > >>> DISTRIB_CODENAME="<your name here>" > >>> DISTRIB_DESCRIPTION="Linux From Scratch" > >>> EOF > >>> > >>> This should solve your problems. > >>> > >>> You must do this, other software needs the lsb_release output. > >>> > >>> Thus, > >>> > >>> lsb_release -ds output comes from DISTRIB_DESCRIPTION > >>> lsb_release -is output comes from DISTRIB_ID > >>> > >>> Notice, in the referred page: Linux Standards Base (LSB) > >>> > >> > >> This problem appeared in the support page. Second time that lsb_release > >> gives problem, if not installed or correctly configured. So, it seems > >> that it is becoming increasingly more important. > >> > >> I am thinking of changing the page in BLFS to include the configuration > >> file, duplicating, somehow, what is in LFS. > >> > > > > > > - usually a bad idea; maintenance headache, quickly gets out-of-sync > > (& then just plain wrong wrt relevance), thus causng new problems, etc. > > Sorry, akh, I do not agree with this. >
Well, there's ample examples of it happening. (But ref last para, below: I think there may be a language issue here re the term 'duplicating'.) > After reading below, I believe you are thinking that lsb_release is on > LFS, Not even remotely so. Strange interpretation ... > but no, installation as a package is in BLFS. But the configuration > is in LFS. This is the problem. Took a while this morning for me to get > the two parts together, expected the configuration in BLFS (as it was > originally), and recalled finally that it was in LFS. That was the > reason I told him to install lsb_release. > > > > > The core of the problem is, I'd suggest, that: openjdk/icedtea code does > > have a bug in that it uses lsb output, and lsb uses the string 'n/a' > > as a default value, and openjdk/icedtea doesn't sanitise for that in > > at least the problematic sed. (IIRC that problematic sed appeared a few > > years back). Whereas, openjdk/icedtea should be able to compile/work ok > > whether without the lsb stuff present or with lsb present and returning > > 'n/a' for values. Thus, further, the lsb stuff should not be a assumed > > to be(come) a prerequisite, unless the openjdk/icedtea upstream says > > explicitly that it is. > > > > It was a user mistake, unfortunately, due to the two parts being in > different books: LFS not properly configured. I'm talking about the underlying cause. In which case, "It was a user mistake ..." is wrong. It's a user 'mistake' on top of an underlying bug, yes. The user should still be able to configure LSB fields with empty-values or similar: and if lsb_... then returns 'n/a', software using lsb_... should be able to handle that. > > > > > Therefore I'd suggest for now at least that: > > ---- > > * on openjdk/icedtea page, include a patch that fixes the problematic sed. > > If I agree with this, other package in BLFS should have a patch, too. > And the new programs that would be discovered to fail. > And your problem is? ;) If a program's not sanitising its input properly, then do you correct the program or the input or both or neither. Per Gregory's post, if lsb script _is_ to be maintained by distros, and not by upstream, then maybe bring lsb_release 'in-house' and patch _it_ to at least not return the '/' , to get quick-fix of icedtea issue; or indeed for quick-fix just require that lsb be configured, and be configured without 'problem' characters being used. Which of course is fragile-code terrain. Yuk. > > > > Perhaps/probably also send same or similar patch to upstream. (They might thank you for it.) > > > > * on openjdk/icedtea page, a link/ref to that lfs 'chapter09/theend.html' > > material on lsb. > > That was my first thought. Problem is that the link in svn should be to > LFS-svn, in rc1 to LFS-rc1, in 7.5, to LFS-7.5. Too complicated, more > than the maintainance you were thinking about, when you seemed to think > it was in LFS. 'the maintenance you were thinking about': no, it wasn't "what I was thinking about". And again, no I wasn't thinking about it being in LFS: what a bizarre interpretation ... As for the linking: cannot the xml/xsl tools handle such stuff - shurely they can - just like how in other parts of the book there are links to elsewhere in same book; &/or an entity/variable whose value changes from 'svn' thru 'rc1' thru ... thru '7.5', and thus links auto-update ? > That made me think of bringing back configuration to > BLFS, too. IIRC, first time lsb_release appeared, the configuration was > in BLFS, not LFS. > I'd guess that's worth a discussion between LFS & BLFS: can that lsb stuff at end-ch09 lfs, be shifted (back?) to BLFS ? > > > > Maybe even somehow formally include it in recommended/required/optional > > deps: but - ref notes above - I'd say at the present stage it'd be at > > most under 'optional', in the absence of any stronger statement from > > upstream. Again: that problematic sed doesn't necessarily mean that > > lsb is any sort of pre-requisite for openjdk/icedtea; the latter should > > be able to at least compile OK without lsb present or lsb present and > > returning 'n/a' defvals. > > It is already in optional. I am intending to promote to recommended. > 'already': added 3 days ago, r12706 . > > > > * on lfs 'chapter09/theend.html' page, perhaps strengthen the wordings "It > > may be a good idea" & "It is also a good idea", and give an example of > > some software that uses lsb (albeit perhaps slightly only-cosmetically > > for at least openjdk/icedtea). > > This part is with Bruce and Matt. > > > > > Perhaps collect the lsb stuff together in its own page in lfs or early > > blfs, if it's deemed 'important' enough now. > > ---- > > > > It is exactly what I was proposing. OK, maybe a language thing. You spoke of 'duplicating', i.e. having the same thing in two different places - and thus having to (remember to) edit the same thing in two different places each time; hence the comments about things getting out-of-sync. Whereas now it _sounds_ like you maybe mean _moving_ (i.e. such that there's only one instance of the info) ? Or what? > > So, at the end *we are agreeing*, what is good. > Or maybe not - depends on what you're _meaning_ (as distinct from _saying_) . rgds, akhiezer -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
