Benoit Knecht <benoit.kne...@fsfe.org> writes: > Hi Goswin, > > Goswin von Brederlow wrote: >> Benoît Knecht <benoit.kne...@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-...@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. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d38qul3t.fsf@frosties.localnet
