Paul Gevers <[email protected]> writes: > As long as the version of the *binary* package is higher than the one > currently built by gnulib, this should just work.
Okay sounds like the recommendation is to use 1:1.0-1 for the git-merge-changelog version going to NEW. Thanks for feedback! >> Will that cause any problems wrt package naming in the future? > > Do you have any specific worries? It feels strange to have two binary packages with the same name built from different source packages in play at the same time, and I feared this would confuse the PTS, bug report attribution, QA tooling (piuparts for gnulib when the NEW package is added?) and testing migration checks. I'm happy to try odd things and see what happens. Maybe this is not unusual, just that I don't recall doing it myself before. Andreas Metzler <[email protected]> writes: > On 2026-01-01 Sean Whitton <[email protected]> wrote: >> Andreas Metzler [01/Jan 12:02pm +01] wrote: >> > I think an epoch is the correct way to do this. > >> Only if you *must* use an epoch. If it can be done without one, it >> should be. > > We use epochs when they are the best solution, not when we "must". They > can always be avoided ("5000000+really+1.0"). > > My advise was for the exact case in question. The package goes from > 20251215-1 to 1.0. That is exactly what we have epochs for: > | Note that the purpose of epochs is to cope with situations where the > | upstream version numbering scheme changes [...] > > FWIW I have also just doublechecked that we are fine regarding "3.2.2. > Uniqueness of version numbers", gnulib package versions went from > 0.0.20060601+dfsg-2 to 20060701+dfsg-1 and never used 1.0. Let this be a reminder why using date-based naming for unversioned git packages really ought to use a 0.0~20123456-1 scheme. I see the 'gnulib' package changing from 0.0.20060601+dfsg-2 to 20060701+dfsg-1 back in 2006 and only later was the git-merge-changelog binary added. I suppose it would have been hard to anticipate this problem in 2006, but that's where general recommendations can help. /Simon
signature.asc
Description: PGP signature
