Bug#662632: RFS: libaio-ocaml/1.0~rc1
Stéphane Glondu <glondu@debian.org> writes:
> Le 06/03/2012 15:22, Benoît Knecht a écrit :
>> 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.
>
> I wholeheartedly agree with that.
I really don't get that argument. Nothing in having a debian directory
in the source hinders any other distribution. And plenty of sources
contain spec files for building rpms to no detriment to Debian. If any
non rpm based distribution picks up libaio-ocaml then I will be happy to
include their specs file too. Nothing is limiting the package to just
Debian there.
I would actualy argue the opposite. Having one single authorative source
that builds everywhere is better than having downloaded the upstream
source and then having to hunt around for where the packaging for your
distribution is hosted. It makes the source more portable not less.
But maybe that is just me and this is more about the layout of the git
repository than about how it gets uploaded. If Stephans Idea below pans
out you will get your non-native package.
> Le 06/03/2012 10:36, Goswin von Brederlow a écrit :
>> 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.
>
> You are free to use native packages for your own (intermediate,
> unreleased) development versions. But the version ultimately uploaded to
> Debian should not be native.
Hmm, I haven't tried that as a workflow but it does sound
promising. Having a single git repository with everything in it and only
rolling an orig.tar.gz for final uploads sounds like it should work
without disrupting the workflow. I will give this a try.
> How you manage your git (or whatever) repository is not relevant in
> chosing whether a package is native or not. Sure, I expect a certain
> layout for repositories under d-o-m umbrella, but I guess I wouldn't
> mind as long as it is obvious how to build the package from the git
> repository (maybe README.source if a plain git-buildpackage doesn't work?).
Given the above idea how would you lay out the git then?
With a moments thought I would have 3 branches:
- master
- upstream
- pristine-tar
All developement would happen in the master branch. Then before the
Debian upload I would merge master -> upstream (excluding the debian
dir), roll an orig.tar from upstream and import that into the
pristine-tar branch, tag everything and finally build a non-native
package. This could all be done with a "make release" so it would be
effortless.
>> 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.
>
> Then maybe libaio-ocaml is not mature enough to enter Debian...
During the first year the API changed a few times till I found one that
worked to my liking. During the last year I've only added things to the
API (like supporting big/little endian on top of just network byte
order) or changed the internal implementation and didn't feel the need
to change any of the existing functions. So I think the API is stable
enough that others could rely on it too.
And the API being stable is the important thing, right?
MfG
Goswin
Reply to: