On 31/08/11 21:49, Russ Allbery wrote:
> Ximin Luo <infinity0@gmx.com> writes:
>
>> OK, thanks for clarifying. I take it then that "should" implies "not
>> necessary" in this policy quote:
>
>> "A copy of the file which will be installed in
>> /usr/share/doc/package/copyright should be in debian/copyright in the
>> source package. "
>
> "should" is documented at the beginning of Policy:
>
> In the normative part of this manual, the words _must_, _should_ and
> _may_, and the adjectives _required_, _recommended_ and _optional_,
> are used to distinguish the significance of the various guidelines in
> this policy document. Packages that do not conform to the guidelines
> denoted by _must_ (or _required_) will generally not be considered
> acceptable for the Debian distribution. Non-conformance with
> guidelines denoted by _should_ (or _recommended_) will generally be
> considered a bug, but will not necessarily render a package
> unsuitable for distribution. Guidelines denoted by _may_ (or
> _optional_) are truly optional and adherence is left to the
> maintainer's discretion.
>
> These classifications are roughly equivalent to the bug severities
> _serious_ (for _must_ or _required_ directive violations), _minor_,
> _normal_ or _important_ (for _should_ or _recommended_ directive
> violations) and _wishlist_ (for _optional_ items).
>
> There are some circumstances involving packages with complex licensing
> where some maintainers like to maintain separate copyright files for each
> of the generated binary packages that contain only the information
> relevant to that package, and in those cases, the copyright file installed
> in binary packages may not be the same as debian/copyright.
>
> In general, "should" means "this is what you do unless you know exactly
> what you're doing and what the implications of making another choice are."
>
>> Right. Actually by "pointing" I meant more specifically "to another file
>> distributed along with the package", in the context of DEP-5 License:
>> blocks.
>
> I'm really not sure I see much utility in doing that, honestly. I know
> that some people, yourself apparently included, see that as a huge win,
> but to me the process of copying the license into debian/copyright is
> trivial, as is putting it in DEP-5 format if one chooses to use that
> format, and I don't really get why there's so much resistance to just
> doing that. And it makes it much easier for, for example, ftp-master to
> review the package and be sure all the licenses are where they should be.
>
>> If the pointing mechanism was well-defined, then lint could detect any
>> "bugs". For example, if we edit DEP-5 such: { a License: block can
>> either have at least 1 paragraph of long-text, or it must include a
>> Location: line that points to an existing file in the same directory },
>> then it's trivial to detect missing files.
>
> See, now you've (to my mind) introduced considerably more complexity than
> just putting a copy of the license into debian/copyright like we're doing
> now.
>
At the cost of some complexity in code, we can eliminate a lot of complexity in
our data. With pointers, it is easier for maintainers to create simple
debian/copyright files. 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.
Sure, it's "easy" to format licenses into DEP-5 long-text format, but each new
maintainer needs to do this for themselves. Once you've been doing it long
enough, you can just c+p it from other debian/copyright files that you know
already have this in. In the spirit of sharing, someone might publish DEP-5
formatted versions of license files, to save other people work. Then someone
else might write a tool to automate this copying into new packages. etc etc etc
Rather than allowing the current scheme evolve into an ugly solution, where
correctness is by implicit unwritten "convention", we can simply make a minor
change to DEP-5 to allow a much neater solution (direct use of license files in
their original format) where correctness is by specification.
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?
--
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0
Attachment:
signature.asc
Description: OpenPGP digital signature