Hi Soren, Soren Stoutner <so...@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
signature.asc
Description: PGP signature
