A profile inspection tool reported that the following lines in /usr/portage/profiles/targets/desktop/make.defaults don't follow PMS guidelines: USE="a52 aac acpi alsa branding cairo cdr dbus dts dvd dvdr emboss encode exif fam firefox flac gif gpm gtk hal jpeg lcms ldap libnotify mad mikmod mng mp3 mp4 mpeg ogg opengl pango pdf png ppds qt3support qt4 sdl spell startup-notification svg tiff truetype vorbis unicode usb X xcb x264 xml xulrunner xv xvid" Lines must be wrapped with a \ at the end of the line. A simple change fixes this bug: USE="a52 aac acpi alsa branding cairo cdr dbus dts dvd dvdr emboss encode exif \ fam firefox flac gif gpm gtk hal jpeg lcms ldap libnotify mad mikmod mng mp3 \ mp4 mpeg ogg opengl pango pdf png ppds qt3support qt4 sdl spell \ startup-notification svg tiff truetype vorbis unicode usb X xcb x264 xml \ xulrunner xv xvid" This guideline is available in all published versions of PMS. In the eapi-3-approved-2010-01-18 version, it is in section 5.2.4. Reproducible: Always Steps to Reproduce:
\ inside "" is ugly... dev-portage, what say you?
It works either way with portage, so we have two options: 1) Fix make.defaults to conform to PMS. 2) Amend PMS to allow quoted line continuations without backslash.
(In reply to comment #2) > 1) Fix make.defaults to conform to PMS. Sounds easy and clean to me. But then you guys already knew that. ;)
Well, PMS says "may" not "must" there anyhow. Seems like a non-issue to me but could be clarified to satisfy pedants.
PMS says: "One logical line may be continued over multiple physical lines by escaping the newline with a backslash." The "may" in "line may be continued" is not talking about the backslash. I thought it'd be an easy fix to commit, and even provided the fixed lines, but apparently it's no quite that simple?
i dont see any good reason to require escapes. people are lazy, so this will likely "break" over time again. fixing PMS to not require them and fixing other PMs sounds a lot saner.
(In reply to comment #0) > This guideline is available in all published versions of PMS. In the > eapi-3-approved-2010-01-18 version, it is in section 5.2.4. The eapi-2-approved-2008-09-25 version says that the backslash is _permitted_ inside quoted strings: "One logical line may be continued over multiple physical lines by escaping the newline with a backslash. This is also permitted inside quoted strings." While in eapi-3-approved-2010-01-18 the second sentence was changed to: "A quoted string may also continue over multiple physical lines in this fashion, so that the quoted string can begin, continue, and end on two or more separate lines." The patch introducing this change (by the reporter, BTW) is here: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=278f6d34647a01119edad0dd182f466c6821f7b7>
so it's a bug in PMS wording. i dont think people (except perhaps the reporter) intended to make the syntax stupidly anal.
As the file follows shell syntax, we should use the "rule of least surprise" and allow line continuation both with and without backslash. Besides, current syntax (without backslashes) is used since 2003 at least.
sure, i wasnt suggesting we explicitly disallow support for backslashes, just that we dont require them. as you say, "least surprise" is the logical solution here.
Would the following change be o.k.? - A quoted string may also continue over multiple physical lines in this - fashion, so that the quoted string can begin, continue, and end on two or - more separate lines. + A quoted string may be continued over multiple physical lines by a simple + newline or a backslash-escaped newline.
(In reply to comment #4) > Well, PMS says "may" not "must" there anyhow. Seems like a non-issue to me but > could be clarified to satisfy pedants. (In reply to comment #8) > so it's a bug in PMS wording. i dont think people (except perhaps the > reporter) intended to make the syntax stupidly anal. From your perspectives, yea, it's annoying to have a rather long document that dictates little things like this. It's a pain to have to memorize and follow. And now you've got me, who's poking you guys about it, which only frustrates things even further. I guess I look obnoxious to you because I spent quite a bit of time pushing arguments about why this hair-splitting change should make it into the portage tree. But you don't have the whole story. This profile tool reports incomplete profile results with (seemingly) non-PMS-compliant files, because it assumes syntax bugs otherwise. From my perspective, fixing this bug with " \" line endings or some other PMS-compliant solution means that the profile inspector will work fully on desktop profiles again, and also that portage continues to be PMS-compliant, which, in itself, is not a bad thing. I'm not trying to be obnoxious. I'm just trying to fix a trivial bug (which I even originally marked as trivial when I posted this) and kill two birds with one stone. Look, the deal is, whatever you guys want to do is what's going to happen. You guys are the ones with the commit access and experience, not me. If red flags are going up about putting " \" at the end of each line continuation, and you really don't want to add them, then I'll just follow through with whatever reasonable decisions you guys make. The only reason I appeared to be forceful is because I'm laying down all the reasons /for/ the change all at once, so all of you are informed as to why this bug should be fixed with " \". Now it's up to you to decide whether that happens. In case anyone thought differently, I am not against adjusting the PMS to match reality, and remove assumptions, and I am not against making portage devs' lives easier by removing or rethinking some of the needly details like these. What I am against is not following PMS guidelines and then not correcting PMS to match reality, since people like myself actually use PMS to write portage-compatible tools. (To avoid any additional misunderstanding, my tone in these paragraphs do not use any sarcasm. I'm trying to get rid of flames in this bug, and work with you guys, rather than against.) So, moving on to discussion of an actual solution... (In reply to comment #7) > The patch introducing this change (by the reporter, BTW) is here: > <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=278f6d34647a01119edad0dd182f466c6821f7b7> ...I actually made this change. I was trying to clarify a line that took me a whole five minutes to figure out, but I guess in the meantime I inserted yet another assumption (that " \" are required) that shouldn't have been there. (In reply to comment #11) > Would the following change be o.k.? > > - A quoted string may also continue over multiple physical lines in this > - fashion, so that the quoted string can begin, continue, and end on two or > - more separate lines. > + A quoted string may be continued over multiple physical lines by a simple > + newline or a backslash-escaped newline. > Fwiw, this looks good to me, and it removes some of the odd wording I had put in there.
Fixed in GIT.
