Benoît Knecht <benoit.kne...@fsfe.org> writes: > Goswin von Brederlow wrote: >> Benoît Knecht <benoit.kne...@fsfe.org> writes: >> > Goswin von Brederlow wrote: >> >> [...] >> >> >> >> The package is native because I am both maintainer and upstream >> >> author. Does a watch file make sense for a native package? >> > >> > That's not what native means. See the third point of [3]. >> >> It says "should" and not "must" and a native package is just so much >> simpler to work with at the current state of the package. Current state >> is about 50 upstream releases to 3 debian changes only releases. >> That might change in the future and then the package can become >> non-native. But for now I feel native is the best way. > > You're of course free to do as you want, but I maintain that it's a very > bad idea, and not doing something right because it's easier to do it > wrong will almost certainly turn out to be much more of a mess and a > burden than you'd have anticipated. > > With the path you're choosing, you're essentially making sure that no > other distribution will ever package your software. They'd have to sort > through every new upstream release to see if anything changed besides > debian/; and when they fall behind on the upstream version simply > because only Debian-specific stuff has changed, their users will start > complaining and they'll have to explain the disparity.
That is what major, minor and subversions (x.y.z) are for. If I change only something in Debian I would not increment x or y and I would not create a new tarball for release on e.g. ocamlforge. On the other hand think what would happen if I use x.y-z but still write a release announcement for every upload on ocamlforge. That would be just as confusing for other distributions. So you see what matters isn't wether it is x.y.z or x.y-z but what you consider and publish as upstream release. > And as mentioned in [4], NMUs will be much more complicated. I don't follow. [4] is about having a debian directory in an orig.tar, which I'm opposed too. Nothing about making NMUs more complicated. How does a native package complicate "dch --nmu"? > I think it important for any maintainer to clearly differentiate in > their mind upstream from Debian, even if they happen to be the same > person. Otherwise, you're artificially limiting your software to Debian, > which is at the opposite side of what free software should strive for. > > Of course, I can't sponsor your package either way, so you can > completely ignore my advice if you wish. But if I was in the position of > sponsoring it, I wouldn't do it based on this point alone (and I kind of > hope prospective sponsors feel the same way). > > I sincerely hope you'll do the right thing here. See my reply to Stephans mail. We might have found a way that works for everyone. > [3] > http://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F > [4] > http://wiki.debian.org/DebianMentorsFaq#What.27s_wrong_with_upstream_shipping_a_debian.2BAC8_directory.3F > > Cheers, > > -- > Benoît Knecht MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org