[ I've added Paul Wise as a CC, as he's a very knowledgeable and thoughtful liason to the Derivatives community. This seems better than CC'ing the entire derivatives list. Paul, any contributions? ] Russ Allbery left as an exercise for the reader: > I don't believe there's any history of using this header in Debian, so I > disagree with this point. The semantics of the field do not fit the way Indeed, Debian would be less likely to use a derivative tag than its derivatives. There's no history for it because the history of large-scale Debian derivatives is only now being written. I can assure you that close to 90% of SprezzOS packages use the flag, as do a great many Ubuntu packages. Furthermore, anyone following the Debian documentation at http://wiki.debian.org/Derivatives/Guidelines is going to use this field. Please see "Packages", second line: "When modifying source packages, rename the Maintainer field to XSBC-Original-Maintainer and add a new Maintainer field." If we're not going to know about this field in lintian, perhaps it oughtn't be recommended to all derivatives. The field being useful, however, I hope it will be retained. Note that for some SprezzOS packages, we're deriving from Ubuntu or even unofficial PPAs. These reference the proper source in XSBC-Orig-Maint. The only packages without such a field are those I've created myself from scratch. > that Debian packages are maintained; Debian never systematically imports > packages from another source, and the package maintainer in Debian is It never systematically does so because there were never sources to systematically import APT packages from. I have seen multiple Debian packages, however, start off with "importing Ubuntu package". While it might not be systematic, it does occur. Furthermore, when it does not occur, the field can just be left out. If you'd like, as I mentioned, I can enlarge the patch so that it only applies to derivatives, based on dpkg-vendor output (or someone else can, which I would prefer). It'd be nice for lintian not to warn on behavior explicitly requested by Debian, though. > wholly responsible for the contents of the package. A Debian package may > be a derivative work of packaging done elsewhere, but that's not the same > thing as the semantics of the field in Ubuntu (who invented the field and > which I assume other derivatives are using for inspiration). I am using for inspiration only the Debian Derivatives Guidelines as maintained on the Debian wiki. I have no idea how Shuttleworth's crew is operating (thank you for the details, though! I was unaware). > There are 10 instances of this header in Debian unstable right now, of > which eight are by the same maintainer (Chris Grzegorczyk > <grze@eucalyptus.com>) who appears to be an unusual outlier (and seven of > those all list the same person as Original-Maintainer). Of the other two > instances, one (mffm-fftw) is completely nonsensical (it lists the Debian > QA Group as the Original-Maintainer). The last is fatresize, which lists > Philippe Coval in both Uploaders and Original-Maintainer, which seems a > little strange. As I noted in the original bug filing, this is a case we likely want to go ahead and flag as being incorrect. Thanks for your detailed response. Having read your thoughts, I would still appreciate the change being made. I will otherwise likely fork lintian for SprezzOS, which I would really rather avoid doing. Have a great day! -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe.
Attachment:
signature.asc
Description: Digital signature