Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: >> > especially if a package maintainer is the upstream. >> This isn't an argument for inclusion of the debian directory (will you >> release a new upstream version just because you need to change a >> build-depends and trigger a rebuild on the Debian buildds?). > yikes... pardon my ignorance if it is not so... quick look at dev-ref > didn't allow me to find a statement that boost in debian revision > doesn't cause triggering of buildd. > > you are saying that increment in debian revision doesn't trigger buildd? > So if I fix a security bug and increment debian revision, that doesn't > penetrate to other architectures? > > if buildd is triggered by deb revision increment as well -- there is no > difference between boosting of the upstream version or only deb > revision...
Of course a change in the debian revision will also trigger the buildds. But this situation is exactly the problem I was referring to: In the -1 debian revision, you'd have a non-native package with an empty diff.gz file (don't even know whether dpkg-source will accept that). In the -1 version, you would have a diff.gz file that contains only a diff against debian/control and debian/changelog. Now this would be very confusing. Especially if there is a bug in the packaging and you are currently not available: A possible NMUer would be very confused. >> ,---- >> | Native Debian packages (i.e., packages which have been written >> | especially for Debian) whose version numbers include dates should >> | always use the "YYYYMMDD" format. >> `---- [...] > If you cited it to > characterize what native package is, then we can debate on the meaning > of "packages which have been written especially for Debian". Yes, I cited it because of this. > First of all *any debian package is written especially for Debian*, > so there is a bit of tautology. Package itself is not a software or > documentation, it is a packaging material (ie debian/) accompanying the > content. "package" in this context is also the name for software here. And for sure a package is *not* just the packaging material; a Debian source package consists of tar.gz and dsc or orig.tar.gz, diff.gz and dsc, and a binary package is a deb file. > Cleaner statement may be something like "i.e. if the packaged material > (e.g. software, images, documentation) is intended to be used primarily > on a Debian-based system and useless on the other systems". That seems > to be cleaner. Submit this as a wishlist bug to the policy. >> > I think that policy/dev-ref is not clear on that at the moment, that >> > is why relevant questions come up from time to time. >> Yes, but the answers given are always the same: Try to avoid a >> debian/ directory in the upstream sources. It's in the archives. > yeap - I saw most of those. And I saw the arguments. And I agree that > having split debian/ helps in few cases. But the same question arises > over and over. May be it is the time to fix the policy to make it > explicit to avoid the debates. How can the Debian policy "forbid" something that upstream is doing? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
