Soren Stoutner <so...@debian.org> writes: > Manuel and I would like to split this into two source packages, based on > these > two upstream source repositories: > > https://github.com/OpenTaal/opentaal-hunspell > > https://github.com/OpenTaal/opentaal-wordlist > > The current dutch package has an epoch for reasons that happened before we > were involved with the package: 1:2.20.19+1-1.
This doesn't look right, because
$ rmadison hunspell-nl -s unstable
hunspell-nl | 2:2.20.19+1-1 | unstable | all
Ie: Wrong epoch, which I hope is just a typo. I also don't think
ftpmasters will agree that a NEW package should have an epoch... I'm
CCing -devel, because introducing epochs must be discussed there, and I
count a NEW package as introducing an epoch.
> If we create a new source package named hunspell-nl, it would also
> need to have the same epoch.
Why not take the opportunity to remove the epoch? The upstream names
are opentaal-hunspell and opentaal-wordlist, so why not:
1. Create src:opentaal-hunspell and src:opentaal-wordlist
2. Use bin:opentaal-hunspell[-nl] and bin:opentaal-wordlist[-nl]
3. Create a dutch metapackage in one of these two NEW src:opentaal.* packages
4. Use versioned Provides, with epoch, in the dutch metapackage.
> As I have never moved a binary package to a new source package, my question
> is
> two-fold.
>
> 1. Should I create an ITP for the new source package, even though the binary
> package it produces is not new? Something about creating an ITP that
> includes
> an epoch feels off to me.
I think that feeling is this: NEW packages shouldn't have epochs.
> 2. When moving the binary package to a new source package, should the old
> changelog be preserved? It seems even weirder to me to have a one-line
> changelog that says “Initial release” that already contains an epoch.
Rather than "moving", why not think about it as new upstream source (via
two packages) and a takeover of the previous namespace?
Please retain me in CC.
Regards,
Nicholas
signature.asc
Description: PGP signature
