Am Samstag, 16. April 2022, 20:09:56 CEST schrieb tony mancill:
> On Thu, Apr 14, 2022 at 10:35:22AM -0700, Matt Taggart wrote:
> > On 4/14/22 06:35, Gerion Entrup wrote:
> > > Hi,
> > >
> > > I'm working in academia and in our research we are experimenting a lot with compilers (and especially different versions and different compilers).
> > > As a general base for our infrastructure we use Debian Stable (Bullseye) especially because backports exist so thank you very much for your work.
> > >
> > > Now we have seen that there are no backports in the compiler field, while there exist versioned packages in testing which are installable in parallel.
> > > The concrete packages we are interested in are clang/llvm-{12..14} (while 14 is only in unstable currently) and gcc-11.
> > > Do you plan to backport these packages? May I kindly ask you to backport these packages?
> > > I'm not a Debian expert but hope that backporting would be relatively simple since the packages are already designed to be installed in parallel without affecting the other ones.
> >
> > This doesn't answer your backport question directly but...
> >
> > Have you considered doing your compiler work inside a chroot/container/vm
> > that is running newer than stable release? That would also let you better
> > control the entire build environment and ensure repeatability, debug more
> > easily, etc. Most Debian development processes do this for the same reasons.
> > You can also have many environments in parallel, add and delete them as
> > needed. You could use one of the debootstrap tools to spin them up with the
> > things you want in them quickly.
> >
> > I suspect once you started backporting compilers there will be additional
> > things you'd want and it might snowball.
>
> Hello Gerion,
>
> +1 to Matt's suggestion to use chroots for this purpose. It should
> give you the flexibility to to use a wider variety of compilers and
> toolchains, including the ability to create your own backports.
>
> I wanted to add that you can likely make the process easier for users
> with some purpose-built scripts. And if those are general-purpose in
> nature, they could become a package in Debian as well (one that we would
> likely need to backport... :)
>
> The schroot wiki [1] may be a good starting point. I also find the
> porterbox instructions [2], and in particular the shell aliases, to be
> helpful.
>
> Cheers,
> tony
>
> [1] https://wiki.debian.org/Schroot
> [2] https://wiki.debian.org/PorterBoxHowToUse
Hi,
thanks for the suggestion but I think that container are not the best
solution for us. This is mainly due to two reasons:
- We have nearly 20 machines with a locally installed Debian, which are
used by alternating people. They are globally managed by Puppet. It
may be possible to provide an image to a VM to all these machines or
copy a chroot container but installing a single package is way easier.
- Most of our users do not have root access. AFAIK, Docker is feasible
without root in the meantime but solutions that require chroot are not
possible without.
In the past, we used two solutions for providing additional software:
- We have compiled it by our own and installed it into some prefix and
then have a script that updates the PATH to include this prefix.
- We have created our own (unsigned low quality) package repository for
backports. Given that there are Debian Testing packages already I
will try to (re)compile those packages for Stable but wanted to asked
here first since official backports would reach more people.
To the snowball effect: This came to my mind, too. However, I think that
multiple compilers are beneficial for a lot of people (not just us) and
they are already present as parallel installable package in Debian
Testing so there seem to be a need for them and as far as I know providing
them should not require any additional updates of other packages.
Cheers,
Gerion
Attachment:
smime.p7s
Description: S/MIME cryptographic signature