[R-pkg-team] Bug#987714: Backlog, 32-bit architectures, endianness and next Bioconductor release.

[Andreas Tille]

Hi again,

what I missed in my last mail: Before we do any large scale uploads we
should decide about bug #987714 of dh-r.  I wonder whether we could
create the list of Depends in the same way as we create Build-Depends
automatically right in the source package.  This is the only idea I have
which enables auto-generation.  If I understood the suggestions inside
the bug report these are all connected to maintaining something
manually.

Kind regards
    Andreas.

Am Mon, Oct 20, 2025 at 03:46:53PM +0200 schrieb Andreas Tille:
> Hi Charles,
> 
> Am Sun, Oct 19, 2025 at 10:57:03AM +0900 schrieb Charles Plessy:
> > Hello everybody,
> > 
> > among the problems we have with our packages, there are:
> > 
> >  - we have a big backlog of new upstream releases, potentially pulling
> >    in new packages.
> 
> Yes.  I was hoping that we could attract some newcomers here since
> Debian packaging of R packages is (usually) brain dead easy since
> (nearly) fully automated.  What do you think about making some noise in
> the scientific community?
> 
> >  - we release our packages on architectures that are not supported
> >    upstream and we struggle keeping up with the porting load.
> 
> We should not attempt to support architectures that are not supported
> upstream.  I agree with the plan from Graham to get rid of these.
> 
> >  - Bioconductor releases every 6 month are costing us a lot of efforts
> >    and some of it is because of the above.
> 
> I wonder if the community sees some value in BioConductor Debian
> packages.  If not we find better ways to spent our spare time.  One
> indicator that the community does not care much is IMHO, that noone
> said:  "Hey, Debian is lagging behind.  How can I help?"
>  
> > One quick conclusion could be that our aims are not sustainable and that
> > we should instead point our users to well-maintained third-party
> > repositories.  But there are two objections to that:
> > 
> >  - We need r-cran-* and r-bioc-* packages as dependencies of non-R
> >    packages.
> 
> Defintely.  I have packaged *lots* of R packages - but never started
> with one that was not requested in some way by the dependency of a
> previously existing Debian package.
> 
> >    Although I do not have an estimate of the fraction of the
> >    current packages needed for that purpose, I expect it to be
> >    significant.
> 
> Its a moving target but the number is significant, IMHO.
>  
> >  - The very existence of sucessful third-party repositories shows that
> >    we can do it in Debian.
> 
> +1
> 
> >    Every day, our toolchain improves and makes
> >    it closer to reality.  For instance, the combination of Salsa and
> >    dgit opens the window for automated updates for packages that do not
> >    change their copyright summary and pass autopkgtests.
> 
> Interesting idea.
>  
> > Yet, in any case I do not see it possible to keep on releasing on
> > unsupported architectures as a default for our packages, given our
> > limited workforce.  It is like running a screen on thousands of packages
> > and claiming the responsibility for fixing the issues.  I only see a
> > future for it if would become a project on its own, with visibility,
> > support, and attracting newcomers.
> 
> +1 for the newcomers.
>  
> > So, I and maybe others have already proposed it in the past, and I think
> > that now is a good timing to do it:
> > 
> >  -> By default, let's have our package depend on architecture-is-64-bits
> >  -> and architecture-is-little-endian.
> 
> Fully ACK.
>  
> > This removes most of the porting challenges, although Debian's arm64 and
> > Apple's arm64 ports have some differences as we have seen earlier this
> > year.
> 
> That should be exceptions and might be helpful for upstream as well if
> exposed by testing in Debian.
>  
> > For this to happen, we will need to update all of our packages.  But
> > hundreds of them are outdated and all Bioconductor packages will need
> > to be udpated too starting from November.  I think that we can do it
> > even if it takes two monthes.
> 
> I might help from time to time (no promises).
>  
> > There are two major challenges down this road:
> > 
> >  - All the reverse dependencies become transitively dependant on 64-bit
> >    and little-endianness.  That is a lot of package removals to ask for
> >    and at the moment I do not have tools to automate that.
> > 
> >  - It can push a lot of stress on Testing and the Release team.  But
> >    maybe we can ask them to remove all the packages from Testing at
> >    the beginning of this sort of transition, and open a RC bug on the
> >    packages so that they do not migrate back until their dependencies
> >    are fixed?
> 
> Graham's suggestion sounded sensible.
>  
> > What are your thoughs, in particular about the two challenges above?
> 
> We should try somehow + make some noise about help we need.
> 
> When I announced to leave the team for my DPL term I realised that we
> have some Uploaders mentioned that are not active any more.  This should
> be cleaned up now fully (those who never responded should be removed
> since it makes no sense to have fake uploaders).
> 
> I'd welcome if we could win more new team members which should be
> doable.  To do so we probably need some team policy document like the
> Debian Med policy which step by step describes how to work inside the
> team.  This is a very helpful reading for newcomers.
> 
> Kind regards
>    Andreas.
> 
> -- 
> https://fam-tille.de
> 
> 

-- 
https://fam-tille.de