Copy: [email protected] (Manuel Guerra)

Manuel and I recently salvaged the dutch source package, which builds four different Dutch language dictionary packages.

https://tracker.debian.org/pkg/dutch

The problem is that the source code comes from two different upstreams, with possibly distinct release schedules.

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. If we create a new source package named hunspell-nl, it would also need to have the same epoch.

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.

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.

--
Soren Stoutner
[email protected]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmglG5oACgkQwufLJ66w tgNnpg/9Ed2n7jSqb+E6CISpWA4q+KAkK+9ZeS4H+uJNCGZXxjmgeWIoBwLamsb7 HuXj/JIoqS2L572cLqApfvCMybGJQk7HLWRW31WCOFiPiR8FJ8vfVw6ZMEwI5zJ9 u9lOEbEXScjotbZrJH4T1SIGUu4ZCHCQZT6M0fu7yMAS2FPo2Q7UejjpwGoiyxfD zOlzITyDark/h8okLGYr9yTSQ+y+gC+53+AFYMTzcEzllWC1wdBruFhoIrscjk+0 4pd3ceGzszg4Rh2CQpoPficxo+I8sPYtosYwG39Tvl1mCbj7epVg+YcxLeyggtqR oPVVtJb2Q13sHfMI4jYj1wzKD28FX5VJA/8grCPlyDeiTBuPUsPoEzhBCnfydVnG nP2iq1Tk8O+csDwYnQxF3f6mONy0kx3aQyuN2QNRs316W65zjEzOc/2WfBRJiL/Q ziwFbq69wId6ipHV/hSWwodiGXo8cLI7gqduQHWAJAxcFjSEm73A6YRhtbtZR01f 0FJxvOpzF2f7qhdGZKmVMEcpn1OoGxEZcwy6TKdlJ/Yz/wzphXnyP2uLBNdtLgL9 FDY3qL23WLizZr65TKEH7Jaag+r1FwC8JV8dRPxaXaAsdJRc2zvPr8CDxQ1IQE1P m15uwCaTNjQ2bL73q7pK1m8Rqbkb4nkSUGL6UIrK4l++5VkZf6c=
=qmzR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-14, Soren Stoutner <[email protected]> wrote:

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 would consider an ITP here 'useless busywork' - if people want to work
on it, they would contact you anyways and not look for a itp to avoid
double work.
To me, ITP's are advisory locking to avoid having several work on the
same thing and maybe to gauge reactions if what you want to package
might be controversial to get feedback before doing the work.

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.

I'd just do "initial separate source release. Split out from src:<otherpackage>" or something like that.

/Sune

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 15/5/25 a las 0:39, Soren Stoutner escribió:

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.

I think it depends on whether or not you consider the new source to be
a successor of the old one.

For example, the hello package which did not use debhelper at first was "forked"
to hello-debhelper. Because it was a "fork", it retained the old changelog.

Later, it became clear that hello-debhelper should be the one having
the name "hello", so the source was renamed back to "hello", also keeping the changelog.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel

Hi Soren,

Soren Stoutner <[email protected]> writes:

On Thursday, May 15, 2025 3:56:50 PM Mountain Standard Time Nicholas D Steeves
wrote:

"adjusting" the epoch also requires discussion, and consensus, on -devel

As far as I know, nobody is proposing adding or adjusting any epochs. All of
these binary packages are going to end up with the same epochs they already have.

Do you disagree with the following?: You're creating two new source
packages that have to pass the NEW queue, you're adding epochs to them,
and your rationale appears to be thus: Because the old multiple-upstream
source package has an epoch, therefore both NEW source packages should
have an epoch.

There's nothing in dsdt-policy about source package naming.

Yes, the NEW binary packages need to provide a greater version than the
old ones, because otherwise upgrades won't occur; No one is saying they
don't need to.

We have
an obligation to avoid epochs whenever possible, and the way that we do
this is by deductively eliminating alternatives such as Breaks,
Replaces, and Provides. Maybe I missed part of this thread? If so,
where can I read that this was demonstrated?

I completely agree. I detest epochs and do everything I can to avoid using them.

I'm happy to hear that, and I hope that you'll be happy to see that
there's a cool solution!

The background (partially explained in the first email) is that this is a package I recently salvaged. It has never had a working debian/watch file and
cannot have one in its current state because the original maintainer combined
sources from multiple upstream sources with potentially distinct release schedules.

Thank you, and I gathered this much :)

As part of bringing the package up to Debian standards, I need to split it into two source packages that match the upstream repositories. At some point
in the past, an epoch was added to this package. I am unaware of the history
of why this was done. I also don’t know why one of the binary packages has an
epoch of 2 (something I learned in this email chain), while the other three have an epoch of 1.

Are you going to preserve the git and imported SVN history? Is the
rationale for the epochs somewhere in that metadata? Obviously there's
no need to check if your plan is to eliminate the epochs.

As much as I would like to get rid of the epochs, I don’t see any way to do
so.

Here's how: Use accurate upstream versions in two NEW source packages.
Their binary packages gain versioned Provides [and Breaks and Replaces,
if appropriate]. In two Debian releases (forky+1), you can you drop the Breaks, Replaces, and Provides. Thus, packages without epochs replace
the packages with epochs, and a pox on the archive is removed.

You can test this by putting the new binary packages generated from the
NEW source packages into a local apt repository. Their "actual
versions" are inferior to the bin packages currently on your system, but
the versioned Provides will take precedence and sort higher, and apt
will install the seemingly lower-versioned replacements. Don't forget
to increment the Debian revision on the versioned Provides ;)

I have never split a source package before, and certainly not one with an epoch. I assumed that the new source package needed to start out with a new debian/changelog, and creating one with a single entry with an epoch seemed wrong to me. However, it was pointed out that when splitting a source package, it is appropriate to maintain the debian/changelog history,

There are multiple solutions to the changelog and package history
problems; do what you feel is best.

in which case I can simply explain in the changelog that the binary
package was moved to a new source package and the previous
debian/changelog history will make it obvious why the epoch was
maintained.

This is not the case, and it will not make the rationale for the epoch
obvious, because earlier you wrote

At some point in the past, an epoch was added to this package. I am
unaware of the history of why this was done. I also don’t know why
one of the binary packages has an epoch of 2 (something I learned in
this email chain), while the other three have an epoch of 1.

which indicates that the changelog is insufficient to explain to the
current maintainer why there is an epoch anywhere in the old package.
If it's not obvious to the maintainer, would it be obvious to anyone
else?

Cheers,
Nicholas

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgnpWYQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYXo1D/4tc7Dh8XkOUSrHyJltoVAGrEB7aXVfDDqJ 1LmijsmagYZEv7Slq0IWPL5T0q6wwWnKlvCmsVh9iWIvU/3p/4V1N/dTmOoJPLj0 VIC2APQ2Ek+aPvR5zKv5ZMIhD6+2rcfAyVTV8cd+NaMbcTnkcHO2VtwA99Kx6lLt wLjPfaFAMtQKiO7y1rNoxLlWaj3WlOIXRHx6Jz327wksJl6ofZednZ68+BAkEFuH XmTdnbWILUUh85gqFtOoir3nS+9UruNqX0bL3aWJjy0DA4pIKf0Rz2AK0qvAAZn1 uXKwUMwdupT5c8VdxeRQrsDnqy5sQ3ND9JfI/phQeEhGEjDhPXQs75jLjKtNlJAf vXyW6ZK7ddlnEiX+b9qF7ajNnKTLf3ZqgQqd9UKeHKTYpkU+ZIeKDjYjOzxzJHAo DQuDr35BhwET7BhB0IHI+F+MVWHa1nralFe+k3N+CzCr98IXunua84dsV3rNH1/a 2VOqBsUD/rBnnMhTiMjr/kB72UqdNcUFMKoPZAvnxsuv1eWq3sIe1YBYeHqtViug L0osHRbYdGcbTwanDFObXNWVGPV4I+wzJUIif5DOnfOcNlQyoYVUZ3lypLXrnbuP Kzm3lEBgR8GNXlAEd8HlUEzLFkCcUQYXQwuvyU58fCqlSQ+IGbFO8Oic3bhigWJr zsFsv73eJg==W59r
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel

On 2025-05-16 Nicholas D Steeves <[email protected]> wrote:

Soren Stoutner <[email protected]> writes:

On Thursday, May 15, 2025 3:56:50 PM Mountain Standard Time Nicholas D Steeves
wrote:

"adjusting" the epoch also requires discussion, and consensus, on -devel

As far as I know, nobody is proposing adding or adjusting any epochs.
All of these binary packages are going to end up with the same epochs
they already have.

Do you disagree with the following?: You're creating two new source
packages that have to pass the NEW queue, you're adding epochs to them,
and your rationale appears to be thus: Because the old multiple-upstream source package has an epoch, therefore both NEW source packages should
have an epoch.

There's nothing in dsdt-policy about source package naming.

Yes, the NEW binary packages need to provide a greater version than the
old ones, because otherwise upgrades won't occur; No one is saying they
don't need to.

[...]

As much as I would like to get rid of the epochs, I don’t see any way to do
so.

Here's how: Use accurate upstream versions in two NEW source packages.
Their binary packages gain versioned Provides [and Breaks and Replaces,
if appropriate]. In two Debian releases (forky+1), you can you drop the Breaks, Replaces, and Provides. Thus, packages without epochs replace
the packages with epochs, and a pox on the archive is removed.

[...]

You seem to propose:
status quo: foo-binary: 2:1.2.3-1
trixie: foo-binary: 1.2.4-1/Provides: foo-binary (=2:1.2.4-1)
forky: foo-binary: 1.2.4-1/Provides: foo-binary (=2:1.2.4-1)
forky+1: foo-binary: 1.2.4-1 without provides

That is too fragile, it will break (by downgrading) on an old entry in
sources list or a local repo.

More generally I also do not think the net-win justifies the work and
risk. epochs are not aestically pleasing but we are used to dealing with
them. I think the huge win of Stouter's plan is to get rid of different versions for source and binary packages, that is something we rarely do (compared to epochs).

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)