Le Mon, Jun 08, 2009 at 10:15:26AM -0400, Jonathan Yu a écrit : > You know, this is probably a stupid question, but what's wrong with > separating file patterns with newlines, as continuations?
Hi Jonathan, first of all, do not worry that your proposition was ignored, but it is sometimes more interesting to wait for multiple propositions to come instead of answering immediately. In this discussion, I will try to limit myself to one message per day (and maybe per thread, I do not know). Also, I am subscribed to -devel in digest mode, to help myself to refrain answering too fast. It is important to leave time to more subscribers of this list to contribute. For the readability of the file, as well as its diffs as you noted, using newlines seems to perform quite well. I think that the biggest drawback is that it is not compliant with RFC-822, which will then necessitate contorsions like in debian/control, to define wihch field is foldable, which is not, which has a special first line,… For the moment, this is not be the only field with this issue: the License field has a special first line, and its newlines are kept after parsing. But maybe it is better to not accumulate exceptions. Note that if we use spaces as separators and claim that the field is 822-compliant, then it is still possible to use newlines as a separator, despite it will still require to escape or quote the spaces in the paths and file names, if it ever happens to be necessary. Let's try to sum up. Currently the DEP contains: * **`Files`** * Required. However, the first **`Files`** field can be omitted and its value will be assumed to be '*'. * List of space-separated globbing pathnames (see `man 7 glob` for more details) indicating files that have the same licence and share copyright holders. * If multiple `Files` declaratioun match the same file, then only the last match counts. My personal wiew about the specification is that it will be best if we keep it short. After all, the old version on the wiki attracted much criticism because it was getting too big. For this reason, I decided to refer directly to glob(7) when I rewrote it as DEP5, so that it would not be necessary to define what the * and ? wildcards are doing. But I like the expectation that the field contents should be pastable to shell commands (like xargs if there are newlines), and glob(7) seems to specify things that are not supported by simple commands such as ls, for instance [:space:] to denote a space. Would everybody agree if the description of the field content would be changed to the following, assuming that it could be made clear somewhere else in the specification that fields are 822-compliant unless stated otherwise: * List of space-separated pathnames indicating files that have the same licence and share copyright holders. Question marks indicate any character and asterisks indicate any string of characters. As wrote earlier, for the cornercases, if for instance a package would contain two directories named 'user manual' and 'user?manual' with a different license, it is probably better to talk upstream anyway, and there is still the possibility of solving the problem at the level of the upstream archive. Discussion of these cornercases could be part of a FAQ if necessary, but my feeling is to not enter into such consideration in the specification itself. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org