On Fri, 21 Apr 2023 at 10:51:16 -0500, Dirk Eddelbuettel wrote:
> Here I just emacs shortcut'ed to 'unstable' whereas as all others I managed
> to put in 'experimental'. That included a 4.3.0rc upload a few days ago.
Yeah, it's unfortunately quite an easy mistake to make. In packages that
have a long-term unsuitable-for-unstable branch, I sometimes resort to
putting code in debian/rules to make it intentionally FTBFS if targeting
unstable (for example see libsdl3).
If you happen to be doing your uploads using dgit, getting into the
habit of explicitly specifying the suite you want to upload to can be
helpful. For example:
dgit push-source -C ../build-area/foo_1.2.3-3_source.changes experimental
> | Hopefully we're close enough to the release that no further uploads of
> | r-base for bookworm will be necessary.
>
> Yes. Please advise. What is best practices now? Upload -2 to experimental?
> Or not? What action would 'close' this bug?
(Disclaimer: I am not a release team member; if they ask you to revert,
please pay attention to them and not me.)
If you're happy with 4.2.2.20221110-2 for bookworm, and there is nothing
else in the R ecosystem that needs to migrate, and there is nothing
fundamentally wrong with the new version for unstable users and the
buildds (just mis-timed), then you *probably* don't need to do anything
special; you can leave it as-is, and close this bug when you are ready
for 4.3.x to migrate (presumably after bookworm releases and trixie
development opens).
There are a few situations where you *would* need to revert:
* if 4.3.0 is broken in some way that makes it bad for unstable users;
* or if there is a bad bug in r-base/bookworm that needs fixing before
the bookworm release;
* or if there is a bad bug in another package (presumably in the R
ecosystem) that needs fixing in bookworm, but building a version of
that package suitable for bookworm would FTBFS or pick up a versioned
r-base (>= 4.3) dependency if built against the new r-base;
* or if the release team or other maintainers report that the new r-base
is causing trouble for the release/migration process
I don't really know how R works and whether it would normally generate
versioned dependencies, so I don't know how much of this is applicable.
I happened to have r-base installed and saw this change go past in
apt-listchanges, but I don't use it myself, and I only have it installed
because it's a build-dep for Lintian.
If you need (or want) to revert, the way to achieve that would be to
re-upload a package branched from 4.2.2.20221110-2, containing the
4.2.2.20221110 source code with the upstream part of its version number
changed to 4.3.0+really4.2.2.20221110. For example look at the recent
history of ccache, mtools or quilt.
And then when the dust has settled, you would upload 4.3.1 if it's
available by then, or otherwise a re-upload of 4.3.0 versioned as
4.3.0+really4.3.0; either to unstable after the bookworm release, or to
experimental (extra-carefully!) sooner than that.
> Also, do I need to contact the release managers to ask for a freeze on this
> misfiled upload?
No, there are several reasons why it won't migrate:
* I opened this RC bug;
* we're in hard freeze and r-base is a key package, so it won't migrate
without a specific unblock;
* the new version makes the autopkgtests of a bunch of other R packages
regress
and any one of those would be enough to prevent migration.
smcv
