Platform Support

[jperkin]

While the goal is to provide useful packages for all POSIX platforms, I think some of them are either unviable, or just do not have enough users to justify. We can't reasonably be expected to support every one-person *BSD fork that comes along, unless that one person is interested in making dreckly their packaging system of choice.

I propose the following platforms be removed.

Interix

I don't think anyone has realistically tried this platform in over a decade, it's almost impossible to even install it nowadays, and I don't see any advantages to it compared to Cygwin which is a far more viable platform for providing Windows binaries and for which we have CI.

MirBSD

Introduced when Benny was a MirBSD developer. I don't know of any MirBSD users other than the author, and they have their own ports tree with no interest in alternatives. libtool support for the platform was dropped back in 2022, so realistically this would involve significant costs.

GNUkFreeBSD

Dead upstream, and I don't believe it holds enough historical interest (unlike e.g. BSDOS) to be supported.

MidnightBSD

One-person FreeBSD fork.

[outpaddling]

+1 on those listed above.

Maybe also drop CentOS 7 (reached end of maintenance June 30 2024) and add a RHEL 8 derivative? Something downstream from RHEL like Rocky or Alma might be more reliable than CentOS, which is upstream now, though not likely by much.

[jperkin]

Just to be clear, this is about whether an operating system is supported at all, rather than just a flavour of one.

As per the project values, if a platform (in your case Linux) is supported, then we aim to support all versions of it. I think you're probably referring to CI. For that we deliberately chosen CentOS 7 as it provides an earlier compiler that helps to shake out any issues with our GCC infrastructure. I think the main Ubuntu 24.04 runner already takes care of newer Linux support and is faster than a Rocky or Alma that I could run in Jenkins.

[outpaddling]

Correct, I was referring to the current CI platforms. I agree that building on Linux distros with the oldest and newest compilers will catch almost all the problems.

I wonder whether it's worth testing on CentOS 7 at this point, though. Nobody should be using an OS 8 months past EOM, and the default compiler, GCC 4.8, has a lot of limitations that will necessitate hacks that aren't relevant to supported platforms. I had to develop a complicated mk.conf setup to use pkgsrc GCC for everything but GCC itself, just to get most packages building on our HPC clusters running CentOS 7. This has not yet been necessary on my Alma 8 installation with GCC 8.

[jperkin]

It's an explicit goal of this project to support older releases. Not necessarily because we think people should be running CentOS 7 (they shouldn't), but because our infrastructure should be designed to withstand bootstrapping from arbitrary compilers, as long as they support the baseline C99. pkgsrc does not have the same goal, and over time has trashed the ability to use platforms that people still care about.

CentOS 7 is a good canary for this, as is shown in #42.

The mk.conf setup that you've had to use that I originally provided to you is something we should fix, not avoid. With the increased speed of compiler requirements these days this will only prove more useful as time goes on. I've done some work on this in the past, and it'll be good to have some time to finish it.

[outpaddling]

It's an explicit goal of this project to support older releases. Not necessarily because we think people should be running CentOS 7 (they shouldn't), but because our infrastructure should be designed to withstand bootstrapping from arbitrary compilers, as long as they support the baseline C99. pkgsrc does not have the same goal, and over time has trashed the ability to use platforms that people still care about.

CentOS 7 is a good canary for this, as is shown in #42.
The mk.conf setup that you've had to use that I originally provided to you is something we should fix, not avoid. With the increased speed of compiler requirements these days this will only prove more useful as time goes on. I've done some work on this in the past, and it'll be good to have some time to finish it.

To be sure we're talking about the same thing here, below is the snippet from auto-pkgsrc-setup/auto-dreckly-setup that enables it (and I haven't used since moving on from CentOS 7). It proved difficult to maintain, as GCC dependencies were constantly changing, but maybe that will be less of an issue with your proposed GCC package restructuring.

    if [ ! -z $base_gcc ]; then
        cat << EOM >> $mk_conf

.ifdef BSD_PKG_MK   # pkgsrc
.if \\
    empty(PKGPATH:Marchivers/bsdtar) && \\
    empty(PKGPATH:Marchivers/bzip2) && \\
    empty(PKGPATH:Marchivers/pax) && \\
    empty(PKGPATH:Marchivers/xz) && \\
    empty(PKGPATH:Mconverters/help2man) && \\
    empty(PKGPATH:Mconverters/libiconv) && \\
    empty(PKGPATH:Mconverters/p5-Unicode-EastAsianWidth) && \\
    empty(PKGPATH:Mdatabases/db4) && \\
    empty(PKGPATH:Mdevel/autoconf) && \\
    empty(PKGPATH:Mdevel/binutils) && \\
    empty(PKGPATH:Mdevel/bison) && \\
    empty(PKGPATH:Mdevel/flex) && \\
    empty(PKGPATH:Mdevel/gettext-lib) && \\
    empty(PKGPATH:Mdevel/gettext-tools) && \\
    empty(PKGPATH:Mdevel/gmake) && \\
    empty(PKGPATH:Mdevel/gmp) && \\
    empty(PKGPATH:Mdevel/gtexinfo) && \\
    empty(PKGPATH:Mdevel/libffi) && \\
    empty(PKGPATH:Mdevel/libtool-base) && \\
    empty(PKGPATH:Mdevel/libuuid) && \\
    empty(PKGPATH:Mdevel/makedepend) && \\
    empty(PKGPATH:Mdevel/pkgconf) && \\
    empty(PKGPATH:Mdevel/m4) && \\
    empty(PKGPATH:Mdevel/ncurses) && \\
    empty(PKGPATH:Mdevel/nbpatch) && \\
    empty(PKGPATH:Mdevel/p5-CPAN-Meta) && \\
    empty(PKGPATH:Mdevel/p5-Module-Build) && \\
    empty(PKGPATH:Mdevel/p5-Perl4-CoreLibs) && \\
    empty(PKGPATH:Mdevel/p5-Scalar-List-Utils) && \\
    empty(PKGPATH:Mdevel/p5-gettext) && \\
    empty(PKGPATH:Mdevel/p5-inc-latest) && \\
    empty(PKGPATH:Mdevel/readline) && \\
    empty(PKGPATH:Mdevel/zlib) && \\
    empty(PKGPATH:Mlang/gcc*) && \\
    empty(PKGPATH:Mlang/perl5) && \\
    empty(PKGPATH:Mlang/python*) && \\
    empty(PKGPATH:Mmath/cloog) && \\
    empty(PKGPATH:Mmath/isl) && \\
    empty(PKGPATH:Mmath/mpcomplex) && \\
    empty(PKGPATH:Mmath/mpfr) && \\
    empty(PKGPATH:Mmisc/p5-Locale-libintl) && \\
    empty(PKGPATH:Mnet/libfetch) && \\
    empty(PKGPATH:Mpkgtools/cwrappers) && \\
    empty(PKGPATH:Mpkgtools/digest) && \\
    empty(PKGPATH:Mpkgtools/mktools) && \\
    empty(PKGPATH:Mpkgtools/pkg_install) && \\
    empty(PKGPATH:Mpkgtools/pkg_install-info) && \\
    empty(PKGPATH:Mpkgtools/pkgin) && \\
    empty(PKGPATH:Msecurity/mozilla-rootcerts*) && \\
    empty(PKGPATH:Msecurity/openssl) && \\
    empty(PKGPATH:Msysutils/checkperms) && \\
    empty(PKGPATH:Mtextproc/gsed) && \\
    empty(PKGPATH:Mtextproc/p5-Text-Unidecode) && \\
    empty(PKGPATH:Mx11/xorgproto)

GCC_REQD+=$gcc_version
GFORTRAN_VERSION=$gcc_version

.endif  # GCC_REQD

[jperkin]

Yeh, this is the approach I showed you years ago, that I still use in https://github.com/TritonDataCenter/pkgbuild/blob/master/include/pkgsrc-gcc.mk as my SmartOS builds always use an in-tree compiler, as did CentOS 6 when I used to build those.

[outpaddling]

OK, regarding CI, I think it would be more useful to know whether a package builds on RHEL 8 than on 7. biology/stacks is an example. It builds fine on my Alma 8 VM, but CI builds failed on both CentOS 7 and Ubuntu.

https://github.com/drecklypkg/dreckly/actions/runs/13641169132.

Ensuring that bootstrap works on RHEL 7 derivatives might be good for QA, but I think it would be better to focus CI resources on platforms that are actively maintained and people are likely to be using.