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. > 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. 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. 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. As much as I would like to get rid of the epochs, I don’t see any way to do so. My original question (posted on debian-mentors) was not really about how to handle the epochs of the binary files, but how to handle the changelog files. 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, 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. -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
