On 08/16/2014 04:18 PM, Raphael Hertzog wrote: >>> - the above layout is for the traditional case of non-native packages, >>> what would be the layout for native packages? how can be differentiate >>> between native/non-native layout? >> >> I've never maintained a native package so I don't really know what are the >> common practices, but AFAICT the only difference would be missing >> "upstream/..." >> tags. Would that be enough for differentiating them? > > Well native = debian is the upstream. So there is no upstream tags created > by Debian but there might be such tags created by downstreams distros that > use the Debian tarballs as upstream tarballs (although I have never seen > this in practice). > > Possibly the best way to notice debian is the upstream is to detect the > lack of debian/master branch (i.e. we use directly master which is usually > for the upstream developers).
The best way to notice that the package is native, is to use what the policy says: the VCS URLs must point to the Debian packaging branch, then you just check the version number. Please don't try to second-guess stuff using branch names. By the way, I try to always avoid using "master" as a branch name. This doesn't express anything at all. > We can certainly recommend it but I don't see the point to mandate it. Then *strongly* recommend it. One of the reason to mandate it could be that we'd have an automated build system which would clone the Git repository, and automatically build using that. This is already what I'm doing with Jenkins, though it's just using HEAD. Having a tagged signature (which would have to be in the Debian maintainer keyring) could be a way to make sure that the Git repository is valid before building. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f01f50.1020...@debian.org
