packages: allow newlines in package description

[ivy]

Summary

a package's description field is typically wrapped at 80 columns for
readability, but there's no way to do this right now; the closest method
is:

	foo_DESC=\
	This is the${.newline}\
	foo package for doing${.newline}\
	things.

but in addition to being slightly ugly, this causes make(1) to insert a
space at the start of each continued line, so the result is:

	This is the
	 foo package for doing
	 things.

to fix this, modify generate-ucl.lua to replace "\\n ?" in a field's
value with a newline character. this means we can write:

	foo_DESC=\
	This is the\n\
	foo package for doing\n\
	things.

which is easier to read, and produces the correct output with no leading
newline since the regexp eats the space after the newline.

modify the description for the yp package to demonstrate this, and also
to be more informative; in particular, it didn't mention "NIS" before,
making it hard to find for someone who wants "the NIS package" and
doesn't know that we call it YP instead.

[emaste]

I'm fine with this, but it looks like we have:

• a shell script
• that invokes `make ... -V ${outname}_COMMENT"
• to obtain the package comment from a make(1)-compatible file
• which we then pass to a Lua script that generates ucl with pkg metadata

Can we just bypass the first three steps and store package descriptions and comments in a file we can use directly from generate-ucl.lua?

[ivy]

In D50150#1143895, @emaste wrote:

Can we just bypass the first three steps and store package descriptions and comments in a file we can use directly from generate-ucl.lua?

i thought about giving each package a "template" ucl file that would contain basic things like dependencies, comment and description, perhaps license, etc., so for example FreeBSD-yp would be templated in release/packages/ucl/yp.ucl or something like that; then generate-ucl.lua could read that and merge the two files to produce the output.

do you think this makes more sense than putting all this in a Makefile? we do need to somehow set LICENSE properly because i'm fairly sure it's wrong for at least a few packages right now...

[ivy]

In D50150#1143898, @ivy wrote:

i thought about giving each package a "template" ucl file

you know, i am just going to do this. the current method is bad, and that is the right way to do it; it means creating a lot more files right now but we need to do it anyway.

i'll close this and re-open it once i've made it good.