Bug#662632: RFS: libaio-ocaml/1.0~rc1
Benoit Knecht <benoit.knecht@fsfe.org> writes:
> Hi Goswin,
>
> Goswin von Brederlow wrote:
>> Benoît Knecht <benoit.knecht@fsfe.org> writes:
>> > Goswin von Brederlow wrote:
>> >> I am looking for a sponsor for my package "libaio-ocaml"
>> >>
>> >> * Package name : libaio-ocaml
>> >> Version : 1.0~rc1
>> >> Upstream Author : Goswin von Brederlow <goswin-v-b@web.de>
>> >> * URL : http://forge.ocamlcore.org/projects/libaio-ocaml/
>> >> Vcs-Git : git://anonscm.debian.org/pkg-ocaml-maint/packages/libaio-ocaml.git
>> >> Vcs-Browser : http://anonscm.debian.org/git/pkg-ocaml-maint/packages/libaio-ocaml.git
>> >
>> > Vcs-Browser should link to something browsable, like a gitweb or
>> > something, if it exists.
>>
>> Oh, I copied that from the browsable webpage itself not realizing that
>> it was a raw view. Fixed. Going to upload 1.0~rc2 after this mail.
>>
>> http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/libaio-ocaml.git
>>
>> >> * License : LGPL-2.1+ and link execpetion
>> >> Section : ocaml
>> >>
>> >> It builds those binary packages:
>> >>
>> >> libaio-ocaml - OCaml bindings for libaio (Linux kernel AIO access library)
>> >> libaio-ocaml-dev - OCaml bindings for libaio (Linux kernel AIO access library)
>> >
>> > You should open an ITP bug and close it in the debian/changelog [1].
>>
>> Given that I am upstream, currently the only user of it and the package
>> is hosted in the ocaml maintainers git I do not think there is a risk of
>> anyone else packaging this as well. Didn't feel like writing an ITP just
>> to raise the ITP count from 1120 to 1121 for a few days when the
>> packaging is done and just pending cosmetic changes.
>>
>> But if that is stopping sponsorship I can certainly write one.
>
> Yes, I think you definitely should. Avoiding duplication of efforts
> isn't the only benefit of ITP bugs; see [2] for a list of reasons.
Filed, pending BTS response.
>> >> To access further information about this package, please visit the following URL:
>> >>
>> >> http://mentors.debian.net/package/libaio-ocaml
>> >
>> > This page shows a few issues already that you should also fix: no watch
>> > file, duplicate short description, and no debian version (i.e. package
>> > is native).
>>
>> I've already fixed the duplicate short description in git, the only info
>> I consider valid problem there.
>>
>> 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.
>> I've tried for a while to maintain the package with split upstream and
>> debian git repositories but it just causes so much extra work for no
>> real benefit. Every upstream change needs to be commited, pulled to the
>> upstream branch of the debian git, merged into master, build, test,
>> repeat. Besides being extra work for nothing it also seriously disrupts
>> my workflow and prevents the use of for example "git commit --amend".
>> You can no longer just play with the source till it works and then
>> commit in an orderly fashion.
>
> I don't see why it would prevent you from using "git commit --amend"
> (although you should never use it once you've pushed to a public
Because with 2 seperate gits I will have pushed/pulled the commit from
one git to the other and then using --amend just creates problems for
the next push/pull.
> repository anyway). In fact, you can make a non-native package even if
> you only have the one git repository; you just need to make sure your
> .orig.tar.gz tarball doesn't contain the debian/ directory. See [4].
Even with a single repository I need to roll out a new orig.tar.gz for
every upstream change or have to commit upstream changes to
debian/patches/* every time I build a source package and send it to
build. The recent change that dpkg now needs "dpkg --commit" is
partially to blame there.
Both ways mean extra work just to build and test a new version. At the
moment the costs simply outweight the benefits. So unless I must change
this I will stick with a native package.
> [1] http://www.debian.org/devel/wnpp/
> [2] http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#newpackage
> [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
PS: Parts of libaio-ocaml (those not specific to libaio) might move to
ocaml-extunix so a bunch more upstream changes are expected in the near
future.
Reply to: