upstream supports debian: wtf?
after a nice discussion on irc and some mail exchange with some upstream
developers it rised that there is no a well defined behaviour a debian
maintainer should keep in this particular situation.
in particular:
1) it is not so clear when native packages should be used instead of the
standard plain ones
2) whether or not debian/ directory should/can/shouldn't be added upstream
3) policy do not cover anything of the above points (should this be covered?)
beware that these points implicate more than what seems at first sight, some
of them follows. please feel free to add others as required.
1) a) using native means that debian maintainer is not so free to make all the
uploads he thinks are required and that every debian release is also
an upstream release
b) any little variation in debian files required to make a good native package
means that on *every* upload we are moving all the sources and not only
modifications, which is the point in using .diff.gz for debian files and
modifications
*note*: i'm not talking about native packages made ad hoc for debian (like
dh-make and many other)! i'm considering legal to make native packages also
when upstream != debian maintainer, policy doesn't forbid this assumption.
developer reference talks about native vs. plain packages, but it seems
somewhat outdated (wiggy, correct me if i'm wrong)
2) a) debian/ in upstream might mean eventually writing access to cvs trees
b) upstream could not trust a new maintainer that freshly adopts their package
c) .diff.gz do not contain all debian stuff (it is widespread between
.orig.tar.gz and .diff.gz)
e) create a mess with cvs-buildpackage (this makes me very very sad)
-----[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Reply to: