Simon Josefsson <[email protected]> [17/Mar 3:00pm +01] wrote: > Sean Whitton <[email protected]> writes: > >> One comment about your patch is that it refers to the other tools' >> documentation for what the contents of the fields should be. But Policy >> should probably become the canonical source here. So can you instead >> document the format of the contents of the fields? > > Okay. I am reaching the limits of my knowledge, so would need help to > finish this. Attaching a first draft for specification. > > This would ideally have to be reviewed by someone familiar with how > uscan/mk-origtargz works (or by me, or someone else, who could be made > to compare code with text). > > The text is silence on how multiple occurances of these lines behave. > The simplest is to just ban that, which could be added. > > If multiple occurances are permitted, the text needs to say something if > the ORDER of those lines matters. > > I think there are two possible interpretations: > > 1) Multiple headers are merged into just one before processing. That > is, first merge all Files-Excluded* headers and exclude all files > mentioned in the merged list of fiels. Then merge all Files-Included* > headers and then re-include all those files. > > 2) Multiple headers are processed in order of occurance in the file. > This means walking through the directives imperatively, applying them > sequentially. > > The corner-case I'm thinking of something like this: > > Files-Excluded: foo/* > Files-Included: foo/bar* > Files-Excluded: foo/bar_foo* > Files-Included: foo/bar_foo_baz > > And a tree like this: > > foo/hej > foo/bar > foo/barbar > foo/bar_foo > foo/bar_foofoo > foo/bar_foo_baz > > With 1) it would merge this into > > Files-Excluded: foo/* foo/bar_foo* > > in which means the second foo/bar_foo* is redundant (which suggest this > is not a valid interpretation) and all files would be excluded, and then > we would have > > Files-Included: foo/bar* foo/bar_foo_baz > > which also contains a redundant line (also suggesting this is not a good > interpretation) so that the resulting tree would be: > > foo/bar > foo/barbar > foo/bar_foo > foo/bar_foofoo > foo/bar_foo_baz > > With 2) the first 'Files-Excluded: foo/*' would exclude ALL files, and > the next 'Files-Included: foo/bar*' would make the tree contain: > > foo/bar > foo/barbar > foo/bar_foo > foo/bar_foofoo > foo/bar_foo_baz > > and then 'Files-Excluded: foo/bar_foo*' would turn the tree into: > > foo/bar > foo/barbar > > and the final 'Files-Included: foo/bar_foo_baz' would turn the tree > into: > > foo/bar > foo/barbar > foo/bar_foo_baz > > So I think 2) is the better interpretation. Now I only wonder if this > is actually how uscan/mk-origtargz really behaves. > > Another question is how to deal with paths containing odd characters > like SPC.
I don't know about any of these details either. But until they are figured out I don't think we should document this. Either Policy defines the field and how it works or it doesn't mention it because it remains, nominally, an experimental extension. -- Sean Whitton
