Ximin Luo <infinity0@gmx.com> writes: > At the cost of some complexity in code, we can eliminate a lot of > complexity in our data. There is redundancy, yes. Is that what you're calling complexity? Or is there some significant complexity in the data of the ‘debian/copyright’ file that you've got in mind? > With pointers, it is easier for maintainers to create simple > debian/copyright files. At the cost of actually making the package more brittle: when taking parts of a package, it is easier to omit a file than to omit part of a file. So a reference is more complex, and prone to failure, than simply keeping all the license information in one place. Now, we compromise that flexibility, in the case of *very* common licenses which are well-known. But I don't see you making a good case for allowing that complexity to increase. > Since there are thousands of packages and there only needs to be a few > DEP-5 parsers (ideally, one), the choice seems obvious to me. Another point of disagreement. I think that multiple competing parser implementations for a standardised data format is healthier and more robust than a single implementation. > Sure, it's "easy" to format licenses into DEP-5 long-text format, but > each new maintainer needs to do this for themselves. That formatting is no different from the formatting they must already learn for the ‘Description’ field in ‘debian/control’. Do you think using the same formatting for another field is a significant increase in complexity? > In fact I might go write the tool I mentioned before and learn some > perl in the process... that's what a lot of Debian devscripts is > written in, right? Formatting a passage of text to that format would be useful, I agree, since it could be used for the multiple metadata fields that have that format. -- \ “[W]e are still the first generation of users, and for all that | `\ we may have invented the net, we still don't really get it.” | _o__) —Douglas Adams | Ben Finney
Attachment:
pgpoO0uFjEaTc.pgp
Description: PGP signature