Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: Can you please invest in some empty lines between your text and the text you quote? This is hardly readable. Thanks.
>> >> > 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? >> > >...< >> Of course a change in the debian revision will also trigger the >> buildds. > that is good that we agree... so what was about your statement:? Well, if the package you uploaded as debian-native has a packaging error, or just needs to be adapted to newer Debian requirements, you have two choices: Either release a new upstream version, which has has no changes relevant for anybody except the Debian buildds. This will confuse your non-Debian users. Or switch from Debian native to non-native packaging - better do that in the first place. If you've packaged it as non-native from the start, we end up in the situation described below: >> >> release a new upstream version just because you need to change a >> >> build-depends and trigger a rebuild on the Debian buildds?). > >> 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). > that is ok to my knowledge It is okay, but it's confusing by itself. >> In the -1 version, > -1 version? may be you meant debian revision? may be -2? Sorry, yes, I meant debian revision -2. >> 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. > can you describe what is confusing in that? I don't really see it... you > don't operate on diff.gz directly anyways -- you are operating on > extracted (and may be even patched) source, so you have all the files. I often operate on diff.gz files. It's easy to look into them, just "less ...diff.gz", and you can check whether the copyright file is okay, whether it uses dpatch, cdbs, whatever, whether a particular patch has been applied, and so on. > Usually you are inspecting .diff to catch what was done wrong, or if > there was garbage sucked in, or to extract relevant patch. If .diff.gz > was missing debian/ it is obvious (to me) that debian is within > orig.tar.gz due to the definition of diff.gz If the diff.gz is missing a Debian directory, the first thing I'd suspect would be that something went badly wrong. After finding out that the directory is in the orig.tar.gz, I'd go on checking in the copyright file whether any repackaging is described. If I find no information about that, I'd think about two possibilities: Either the debian directory is in the orig.tar.gz file, or the packages didn't document their repackaging. For both cases, the best approach would be to file a bug... >> > 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. > ok - let me make an analogy to describe what I meant: "this book > containing fairy tales from around the world was written especially for > our kindergarden"... And you expect that the kindergarden in the neighborhood will not be interested, never? And you also expect that the people working there will never get a different opinion how a fairy tale book should look like? If the people working with the newest group of younger children try out something new (i.e., Debian policy is changed for the next release), shouldn't the book be still the same for the ones working with the older groups? >> How can the Debian policy "forbid" something that upstream is doing? > :-) Good questions with simple answer: it can't. That is why over and > over again everyone advices upstreams to place /debian directory aside > of orig.tar.gz. And lest don't get into the loop describing why it is > bad... ooo - actually it might be worth to compose a wiki page where > people can add to pros/cons... I've never read a pro, except "I'm both upstream and Debian maintainer, and it's convenient for me", which is a short-sighted argument. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)