El 12/08/24 a las 00:15, Bastien Roucariès escribió: > Le lundi 12 août 2024, 00:04:15 UTC Henrique de Moraes Holschuh a écrit : > > > salsa. Some user used +deb12u1~1 > > > but it is not safe against +deb12u1~debu11u1 upgrade for instance. So a > > > suffix > > > like ~pre should be used, and should be documented > > > > Maybe we could set aside "~~~" for such uses. ~pre is not going to be > > foolproof. > You mean ~+~pre ? because +deb12u1~~~ is before +deb12u1~debu11u1 and we want > to upgrade to deb12u1~debu11u1 to deb12u1~+~pre1 to +deb12u1
~+~pre reads like too much. I would prefer something simpler. The corner(*) case you are describing is: there is a preview package available via salsa ci/aptly job or whatever; we want a bullseye user to avoid upgrading to that preview package, while still being able to upgrade to the actual bookworm package. Please, tell me if that doesn't match your thoughts. The broader question is how we *should* version an in-development package. Myself, I tend to avoid using the final version in the VCS until I release, to avoid creating any confusion for anyone looking at the repo (or if I make the build artifacts available via aptly). So I use gbp dch -S that creates a snapshot debian/changelog with a suffix ~N.gbpCOMMIT_ID, but that is not safe for the corner case you describe. (*) and this is a very corner case. We are talking about PPA-like repositories that only informed users would enable. But let's try to be in the safest possible place anyway. > > I am *very* happy that ~deb sorts later than ~bpo, as that updates a > > backport to a stable / oldstable / oldoldstable update. > > > But that was sheer luck. This is not true for ~pre, but would work for > > ~~pre or ~~~~whatever... > > Yes sheer luck do +~+pre will do the trik and be safe against +~ck of > javascript ~+N... (where N is [0...)) would do the trick?
signature.asc
Description: PGP signature
