Bug#662632: RFS: libaio-ocaml/1.0~rc1
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.
> >> 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].
> 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
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].
[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
Reply to: