> George Danchev <danc...@spnet.net> writes: > > > Candidates for policy so far: > > http://people.debian.org/~danchev/survey/sorted/4policy > > (Multi-Arch field added) > > Oh, good, that's less than I thought there would be.
IMO, standardized fields (non-XBSC) are quite well documented in policy, and I didn't expected to find so much of it, however user-defined fields (XBSC) are not at all documented and couldn't be easily reused. > We should probably > add Origin as well. Yeah, I added Origin to my `4policy' for now. > > The rest are user-defined fields (X[SBC]) which are possible candidates to > > be documented in devref or wiki.d.o, since they seem more volatile to me: > > http://people.debian.org/~danchev/survey/sorted/ > > However, I couldn't be precisely sure about the intentions of their > > creators, > > possible values, and parties supposed to honor or consume them as well. > > Autobuild should probably go into Policy. It's used for non-free packages > to indicate that it's legal for the buildds to build the packages. > > Original-Maintainer is odd -- Ubuntu uses that for packages imported and > modified in Ubuntu, but I'm not sure what it's being used for in Debian. > It seems like it might be worth documenting, though. Autobuild and Original-Maintainer are user-defined (XBSC) and I thought that policy should only mandate how user-defined fields are constructed as it does in #5.7. Concrete user-defined fields are subject to the user, eventually well documented so that can be reused by others. Make sense? > I wonder what's up with all the Gstreamer and Npp fields. These and Tads3-Version seem like a blatant abuse of user-defined fields mechanism to me. -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
