Re: installation-guide_20220129_source.changes ACCEPTED into unstable
Hi,
Samuel Thibault <sthibault@debian.org> wrote (Sun, 30 Jan 2022 14:26:52 +0100):
> Holger Wansing, le dim. 30 janv. 2022 13:42:10 +0100, a ecrit:
> > Samuel Thibault <sthibault@debian.org> wrote (Sun, 30 Jan 2022 13:23:25 +0100):
> > > In general 3.69 -> 3.68+deb11u1 update looks wrong, it has to be
> > > increasing :)
>
> Mmm, sorry, even if that's what caught my eye, this isn't an absolute
> rule.
>
> > Hmm, increasing is of course right.
> > However, I guessed this goes per distribution, so:
> > current version in stable is 3.68, that's why I chose 3.68deb11u1.
> > Looking at the version history in stable, that would be indeed an increase.
> > ?
>
> Yes, and that's usually what happens: we upload to stable some patched
> versions of what is already in stable.
>
> > So, if I understand that correctly:
> > - I do an upload to unstable now, which is then 3.69
>
> Yes.
I have prepared this upload in git now.
During this, however, I noticed that I cannot do this upload myself,
because it adds new packages to the archive (only task-* pseudo-packages,
but new packages anyway), and so that requires an binary upload, which I
am lacking permissions for.
Therefore, could someone upload tasksel 3.69 for me, please?
> > - Then I can upload to stable, which then gets 3.69deb11u1
> > Would that be correct?
>
> It would have to be less that 3.69 actually, so that on upgrading to
> bookworm the package gets "upgraded" to 3.69.
>
> I guess best would be 3.69~deb11u1, to say that it's essentially 3.69,
> but before 3.69 from bookworm.
Hmm, my intention was to only bring one of the latest changings into stable
(the "install CUPS on desktop systems" part), not everything.
The reason for this was: I'm unsure how uploading to stable would work,
if a combination of binary-upload + source-only-upload is needed (due to
policy after adding binary packages).
To keep this whole thing simple, my intention was, to only port the CUPS
changing to stable.
What would be the best versioning scheme for that then?
(The new version in stable would not be "essentially 3.69" then.)
Holger
--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Reply to: