XPost: linux.debian.devel.mentors
Hi Soren,
Soren Stoutner <
soren@debian.org> 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)