Bug#662632: RFS: libaio-ocaml/1.0~rc1
Benoît Knecht <benoit.knecht@fsfe.org> writes:
> Goswin von Brederlow wrote:
>> Benoît Knecht <benoit.knecht@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
Reply to: